[ENH] Add AutoETS Algorithm

[alexbanwell1]

Reference Issues/PRs

What does this implement/fix? Explain your changes.

Adds AutoETS

Does your contribution introduce a new dependency? If yes, which one?

No

Any other comments?

PR checklist

For all contributions

• I've added myself to the list of contributors. Alternatively, you can use the @all-contributors bot to do this for you after the PR has been merged.
• The PR title starts with either [ENH], [MNT], [DOC], [BUG], [REF], [DEP] or [GOV] indicating whether the PR topic is related to enhancement, maintenance, documentation, bugs, refactoring, deprecation or governance.

For new estimators and functions

• I've added the estimator/function to the online API documentation.
• (OPTIONAL) I've added myself as a __maintainer__ at the top of relevant files and want to be contacted regarding its maintenance. Unmaintained files may be removed. This is for the full file, and you should not add yourself if you are just making minor changes or do not want to help maintain its contents.

For developers with write access

• (OPTIONAL) I've updated aeon's CODEOWNERS to receive notifications about future changes to these files.

[aeon-actions-bot]

Thank you for contributing to aeon

I have added the following labels to this PR based on the title: [ enhancement ].
I have added the following labels to this PR based on the changes made: [ forecasting ]. Feel free to change these if they do not properly represent the PR.

The Checks tab will show the status of our automated tests. You can click on individual test runs in the tab or "Details" in the panel below to see more information if there is a failure.

If our pre-commit code quality check fails, any trivial fixes will automatically be pushed to your PR unless it is a draft.

Don't hesitate to ask questions on the aeon Slack channel if you have any.

PR CI actions

These checkboxes will add labels to enable/disable CI functionality for this PR. This may not take effect immediately, and a new commit may be required to run the new configuration.

• Run pre-commit checks for all files
• Run mypy typecheck tests
• Run all pytest tests and configurations
• Run all notebook example tests
• Run numba-disabled codecov tests
• Stop automatic pre-commit fixes (always disabled for drafts)
• Disable numba cache loading
• Push an empty commit to re-run CI checks

[alexbanwell1]

Branch based off AutoARIMA branch, to avoid file conflicts when that is merged. Need to work out how to deal with ZeroDivisionErrors in the loss function, as currently number is not used in the main AutoETS function as it needs to catch any ZDEs

[alexbanwell1]

Also Added at the top of the AutoETS forecaster class:
Attempts to make this forecaster stable:
- Issues with Zero division Errors:
- If any data points are non-positive, multiplicative options are excluded.
- With numba fastmath=true, the compiler moves the operations around. This means
zero division guards are ineffective. As such I have tried putting the guards
in a separate fastmath=false function, with inline=true. This slows it down a
lot though.
- Need to make sure initialisation function never assigns slices of the data
array
- fixed bug where the first few values were being changed in the seasonality
calculation array
- Issues with the nelder mead not finding good parameters,
usually ending up with alpha approx 1:
- Tested updating the initial conditions (initial level, trend,
seasonality array) to be heuristically calculated across the whole
array at the start.
This seemed to fix some issues, but cause others.
- Tested optimising over the initial conditions in the nelder-mead array.
This didn't really help, although is how statsmodels does it.
- Added guards to the nelder-mead algorithm to reflect points back in when they
go above or below (0,1) to ensure parameters stay valid.
- Added sigmoid function to output of nelder-mead to ensure parameters stay
in (0,1).
- Initialised the simplex array with reasonable starting values
(a=0.4, b=0.25, phi=0.95, g=0.35)
- The algorithms sometimes produce really extreme forecasts of the order of 1e100
larger than the data. I assume this is due to the guards on the zero division,
but haven't been able to work out how to fix it.