[BUG] fix BoxCoxTransformer failure after scipy 1.11.0

[fkiraly]

Fixes #4769 by using scipy's on-board box-cox-fitter for methods "mle" and "pearsonr" and enforcing positive values.

The reason for the failure was use of negative values in some interface test cases, which previously would produce garbage results but scipy would not complain. As of 1.11.0, it complains (albeit with a confusing error message that makes it hard to track down that it is in fact from negative values in some test cases). See further discussion here: scipy/scipy#18761

This is now solved by introducing an enforce_positive argument to BoxCoxTransformer, which ensures positive values before fitting. This can be turned off to obtain the previous behaviour, but for positive values it will be the same (although with an additional np.sign and np.abs calculation that should be fast).

Also makes the following changes, while we're cleaning this up:

• The sktime box-cox-fitter in BoxCoxTransformer was not using scipy's since the latter did not have settable bounds when the former was originally implemented. I have hence replaced it with scipy's own box-cox-fitter and using a bounded optimizer if bounds are passed, from scipy 1.7.0 on where it exists in the form we need. Pre-1.7.0, I've left the old behaviour.
• improved docstring - general improvements, removed some wrong math statements, made clear what the choice of method means and when it interfaces scipy
• added a "fixed" method, which allows to use the transformer with a fixed parameter - or tune it via grid search.
• input checks on method

Note: the fix is behaviour changing, but imo does not require deprecation because it changes some behaviour from buggy/misleading (only in the sub-case where negative values were passed) to sensible.

[fkiraly]

update: just learnt that an initial bracket need not contain bounds - so I simply set the bracket to bounds if provided, while passing bounds if provided also to the optimizer (constrained)