Add preparation mechanism

[adrhill]

SCT could benefit from the addition of a preparation mechanism.
The following points primarily apply to local patterns, but don't harm global pattern detection.

1. Heuristics for the selection of pattern representations

The benchmarks in #211 have (once again) shown that there is no free lunch when it comes to the best internal pattern representation, as it depends on (a) the sparsity of the given function and (b) the size of index sets over the entire compute graph. The most-user friendly solution to this problem would be to introduce a heuristic, e.g. on input size¹.

Since such a run-time selection of internal types is by definition type unstable, this heuristic should be moved outside of any hot loops, e.g. by moving it to a type-unstable preparation mechanism.

2. Avoid repeated input enumeration

Local pattern detection methods currently enumerate index sets on every call. This could be avoided by returning a reusable buffer when calling the preparation mechanism.

This feature will get more important in the context of reusable chunked index sets (see #194).

3. Chunked Hessian detection?

A preparation mechanism for Hessian patterns that first computes a global hessian pattern might be a possible avenue for chunked local Hessian detection.

4. Composability with DI

Ideally, SCT's preparation mechanism should be designed with DI's preparation of AutoSparse backends in mind, as the former should be called within the latter (CC @gdalle).

Footnotes

1. In theory, the heuristic for local pattern detection could also call global pattern detection methods to get an upper estimate of the sparsity of a Jacobian/Hessian in addition to the input size. ↩