Description

Currently, we have integrated generation of decomposed footprints into our existing footprint functions via an extra decomposition= parameter. But there are some disadvantages to this approach:

• The decomposed footprint isn't always equivalent to the dense footprint. When this is the case is complicated to explain in a docstring, and probably surprising to users.
• Coupling decomposed and dense footprint generation makes it more difficult to extend any of these algorithms, e.g. if we want to extend the supported number of dimensions we need to figure that out for the other algo as well. Otherwise it get's messy to document.
• Having a function return a completely different type (ndarray vs. container with inhomogenous types), makes typing a lot harder. Code using the result now needs to account for both possible scenarios.

Instead, after discussion with @stefanv, I propose to split that stuff into their own functions. Exactly how, is something we can figure out (see #7628 (comment) for more thoughts on this).

Can be closed, when we have deprecated all occurrences of the decomposition= parameter and provide new public functions for the old behavior.