Replacement parameters

It should be possible to (somehow) specify simple cases of parameter replacement. Say, 1-to-1 or n-to-1 parameter replacements in which 1 (or multiple) parameters are replaced by 1 new replacement parameter.

The parameter deprecation call should allow specifying:

* which parameter is the replacement
* that passing both should be an exception (and default to raising one)
* an optional "transformation" to apply to the argument passed into the deprecated parameter which either:
- [ ] converts the old argument into one for the new replacement (e.g. `lambda old_value: _from_legacy(old_value)` would pass the upconverted value into the new replacement parameter).
- [ ] passes the old argument through as-is (and thereby simply raises the deprecation warning)
- [ ] drops the argument entirely (i.e. ignores the old argument entirely. The advantage is that the call signature of the wrapped function can already remove the deprecated parameter, making its deletion slightly easier.)

(The deprecation message should then also list the replacement parameter, as it does for `regret.callable`).

Start by reviewing the parameter deprecation call and the existing regret.callable behavior mentioned in the issue. Define how 1-to-1 and n-to-1 replacements, conflicts, transformations, passthroughs, dropped arguments, and replacement text should work; done means these cases are specified and covered by tests.

Written by the indexing model from the issue text.