…rn canonical-variant wildcard loss

…attern variant comparison (rule application)

(this change is marked as a *workaround* rather than a 'fix' per se, since the issue it tackles instead likely has its root in the current behaviour regarding the binding of 'wildcard' symbol variants (-outside the context of pattern matching / replacement.
(See the closing of this message for a further remark on this point.))

Explanation:
- Currently, because canonicalization of expresssions involves wildcard  binding as part of symbol binding (this may be undesirable / a bug), it is presently necessary that a new scope be created upon 'match' pattern canonicalization (performed for optimization purposes) in rule application:  with this otherwise running the risk of present wildcard symbols being bound to definitions in the current scope...

For example, before this change:
```
ce.expr(['Add', 'x', 3]).replace({ match: ['_', '__'], replace: 'y'});

// →Expectedly captures wildcards, and replaces
// top-level expression.
// *However*, the canonical-request of the 'match' expression within 'applyRule'
// results in symbol/wildcard '_' being attributed a function-definition
// (type='function'): within the scope in which this 'expr.replace()' was called

// Consequently, a subsequent replace call involving a universal wildcard
ce.expr(['Add', 'x', 3]).replace({ match: ['Add', 'x', '_')], replace: 5 });

// → Returns 'null'... (assuming this call made with an unmodified/same scope as the previous)
// Ultimately because the same point-of-canonicalization results in the Universal
// Wildcard in this instance uptaking the previous, 'function' definition, resulting
// in a MathJson-internal type-error for the canonicalized match-pattern variant
// in this instance, resulting in an absent wildcard in the canonical variant,
// and leading to an early exit from rule-application 'applyRule()'

//For illustration, the canonical-variant of the initial, non-canonically boxed
// `['Add', 'x', 3]` pattern results in the canonical-variant as:

[ "Add", "x", [ "Error", [ "ErrorCode", "'incompatible-type'", "number", "function", ], ], ]
```

*Note*:
- This 'fix' may no longer be necessary, if canonicalization of wildcard-containing expressions were to no longer perform name-binding on these (this may be unintentional?)

…onical' value during 'applyRule()'

…ition'

Before: passing around a rule with '{ match: .., condition: 'non-delimited LatexString }' would fail to yield/parse a condition.

Now: cases such as the previous result in a parsed condition (yet, presence of display/inline mode delimiters *should* still be admissible)

…so that it may evaluate)

…ctural'

…fyNonCommutativeFunction

(This inadvertently resulted in *full*-rule simplification of all operands for all functions
Correcting this has resulted in *no broken tests*)

…umeric operands of 'lazy' operator definitions

Explanation
------------
'evaluateNumericSubexpressions()' (function, which is notably called
within the 'simplify' process only for operator-definitions with flag
'lazy' set to 'true', and operator 'Divide', presently fully evaluate
all (more-or-less) numeric operands during simplification.
At least a couple of problems exist with this, mentionably that
'simplify' is, use-case depending, likely not called with intention to
*evaluate all numeric* operands/expressions. However, related to this,
and really a more primary issue here, is that proceeding with this
unconditionally is troublesome in terms of simplifying in the context of
any given rules: particularly when the ruleset is a custom one, or an
incomplete subset of the default ruleset.
For example, consider the simplification of an 'Add' expression with
evaluable 'Ln' or 'Log' arguments... If the accompanying simplify
rule-set does not with it include rules covering the simplification
(perhaps, 'evaluation') of this set or category of functions, then it is
dubious that these should be evaluated prior to be being summed...
(instead - given a ruleset consisting of a single rule which handles
'Add', an input such as 'Ln(e) + Ln(e)' should understandably reduce
this to '2 * Ln(e)' (instead of simply '2'); the case therefore of a
fuller simplification being dependent on presence of separate rules
handling Ln/Log.
(Another illustrative example, is that at time of commit, input '3!'
will remain unsimplified (unevaluated)... illustrating the need for a
requiring/wrapping operator (with a 'lazy' flag) for its evaluation)

\*Stemming from this consideration, it may be worth considering a
single, or set of 'evaluation'-rules: decoupled from respective
simplification rules (plain/eager evaluation of trig., vs.
identities/construction, for example)

… considering replacement expr. sameness, also consider expression 'form'

- A switch to 'form' allows specification of 'structural', and also an explicit specification of 'raw'.
- As per inline documentation, the same/previous behaviour can be replicated, by first ensuring the entire input bears the same form as any speified replacement form.

- When considering 'successful' rule application, any differences in expression form before-> after is now considered, in spite of these anyway bearing structural similiarity.

- The same change would likely benefit from being made on `expr.subs()`.

In disuse: but set for employment particularly in test-files

…explictly 'raw'

'transform()' is a wrapper around 'replace()' - always acting recursively - and offers an ergonomic means to match sub-expression targets and apply common fundamental operations/transformations in an expression 'tree', without the need for custom 'Rule' logic / workarounds.

Change includes tests.

- The typing of 'TransformOptions' has necessitated that 'SimplifyOptions' be shifted from its previous home of 'types-definitions(.ts)', to 'types-kernel-evaluation.ts'. It has also been made generic over Expr/SemiExpr/CE, in a similar way as for its sibling types (such as 'RuleReplaceFunction').