Aside from this previously being a needless operation (when 'recursive'
was specified as 'true') - previously this sometimes erroneously return
'true' for a recursive/operand match (already-matched operand which has
been replaced by an expression with the same structure).

- Also account for canonical-status of the *replacement*-expr. for
  successful replacements.

- If 'canonical' is not specified as an option during replacement:
  - There is differentiation between canonicalizing any direct
    replacements (i.e. these may be recursive), and the overall/input
    expr.
  - ^In this case, each canonical-status, of sub-exprs. will generally
    be *preserved*: but will 'opportunistically' mark expressions as
    canonical (e.g., because replaced operands are now canonical)

- easier to follow (at least from outsider's perspective)
- removes unnecessary/duplicate stmts.

- In essence, more-or-less 'fixes' expr. matching behaviour for patterns
  involving sequences. These changes result in the following variety of
  cases successfully matching where they would not have done
  prior:
    - Sequence wildcards matching >1 operand, e.g.:
      - ['Add', '__a', 'x'] will now match ['Add', 1, 2, 3, 'x']
    - Multiple sequence wildcards (at the same level), e.g.:
      - ['Tuple', 1, '__a', 4, '__b', 7, '__c'] will now match ['Tuple',
        1, 2, 3, 4, 5, 6, 7, 8]
    - Handles behaviour, and operand/expression capturing for cases of a
      regular sequence wildcard, followed by one+ optional-seq.
      wildcards, e.g.:
      - For ['Multiply', '__f', '___g', '___h'], 'f' will now match
        'greedily' and essentially 'merge' with following sequences,
        such that 'g' and 'h' each capture '0' operands/each: this
        experientially being the preferred/expected behavior.
         (^note that sequences of (regular) sequences do not need to be
         accounted for since these are considered 'invalid' anyway
         (a subsequent commit set to account for this))

  The fact of these cases failing to match has hitherto been obscured on
  account of absence of tests (these have now been added).
  Changes/fixes have been achieved by trying permutations of quantity of
  operands/expressions matched by sequence wildcards (this logic appears
  to _mistakenly_ have been absent prior), as well as special
  'lookahead' checks for cases of 'regular/optional sequence' cards.
  'matchArguments' - where the majority of these changes are situated,
  has (should) now also be refactored for readability.

- 'patterns.test.ts': re-writes, almost entirely, the test cases &
  structure throughout, including addition of/more particular tests,
  increased qty. of matchers within each, & a healthy handful of
  controls.

- Also:
 - Reverts/fixes the condition of argument matching skipping pattern
   permutations with sequences/sub-sequences consisting of a regular
   sequence wildcard followed by a universal ('_') wildcard (consider
   ['Add', '__a', '_b']. Whilst in some sensitive intuitive - if
   considering sequences as 'greedy'-matching - this sequence of
   wildcards clearly has matching utility for some cases (notably this
   was breaking some existing tests, too).

- Add direct handling for basic integrals: e^x, sin(x), cos(x), ln(x), x^n
- Handle e^x parsed as ['Power', 'ExponentialE', 'x']
- Clean up permutations() function: remove commented-out code and fix typing

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>