Evaluating `AHM_ANALYSIS` - deprecate, fix, or something else?

The `AHM_ANALYSIS` is somewhat broken in that it consumes a lot of memory.
See the following issues for details:

Old issue discussing memory issues that are still prevalent:
- https://github.com/equinor/semeio/issues/318

Newer reports of memory issue:
- https://github.com/equinor/fmu-drogon/issues/11

The idea of `AHM_ANALYSIS` might be good and parts of it can perhaps be of use in the new `Analysis report`.

**Questions:**
- Should we just deprecate and delete it?
- Should we put in the effort to understand it, re-factor, etc.?
- Should this be done as part of the `Analysis report` milestone?

## What does `AHM_ANALYSIS` do?

The code itself is documented in this docstring:
https://github.com/equinor/semeio/blob/aa6107916e0cb1ea09301c093508600ec573bbbc/src/semeio/workflows/ahm_analysis/ahmanalysis.py#L19-L57

There's also this wiki entry:
https://wiki.equinor.com/wiki/FMU_drogon/AHM_ensemble_analytics

## Is it in use?

I searched the logs and there seems to be a tiny bit of usage:


Note that it is required to create input for the `AssistedHistoryMatchingAnalysis` plugin in `webviz-subsurface`, but we don't know if this is in use.
The original author of both the workflow and webviz plugin has left the company.

## Other issues related to `AHM_ANALYSIS`:

- https://github.com/equinor/semeio/issues/498

Start with the docstring in src/semeio/workflows/ahm_analysis/ahmanalysis.py and review the linked semeio, fmu-drogon, and semeio issues. Check the reported memory problems and current usage, including the AssistedHistoryMatchingAnalysis plugin dependency. Done means reaching and documenting a decision to deprecate, fix, or otherwise handle AHM_ANALYSIS.

Written by the indexing model from the issue text.