Inverse plans

To me it seems a bit unintuitive that `AbstractFFT` assumes that plans have a field `pinv` which is populated when calling `inv`. When computing the inverse via `inv` I don't expect the provided element to be mutated.

I would suggest to replace `plan_inv` with `inv` such that calling `inv` returns the inverse plan but does not mutate the given plan. Similar to `ScaledPlan` a wrapper type could be provided that contains a plan and its inverse (e.g. as fields `p` and `pinv`). In my opinion, this would make computing and caching of inverse plans more transparent. Additionally, it would allow plans to be immutable and strictly typed (and hence maybe improve performance?).

What do you think?

Start by reviewing AbstractFFT's plan_inv and inv behavior, then compare the existing ScaledPlan API. Determine how inverse-plan computation and caching should avoid mutating the supplied plan, and consider the proposed wrapper with p and pinv fields. Done means the API design is settled and its effects on immutable, strictly typed plans are evaluated.

Written by the indexing model from the issue text.