Avoid double caching in mappers that derive from CachedMapper

[majosm]

If a mapper derives from CachedMapper and overrides rec in a way that implements caching, it needs to call Mapper.rec instead of super().rec in its implementation in order to avoid executing the cache lookup/insertion logic twice. This PR intends to fix that.

The naive version of this fix had the unfortunate side effect of breaking deduplicate_data_wrappers, because it turns out that deduplicate_data_wrappers was taking advantage of this behavior in CachedMapAndCopyMapper in a subtle way. Here's a sketch of what was happening in the previous implementation:

Suppose we have 2 data wrappers a and b with the same data pointer.

With super().rec:

1. map_fn maps a to itself, then the mapper copies a to a'; it caches the mapping a -> a' (twice, once in super().rec and then again in rec),
2. map_fn maps b to a, then the mapper maps (via cache in super().rec call) a to a'; it caches the mapping b -> a'.

=> Only a' in output DAG.

With Mapper.rec:

1. map_fn maps a to itself, then the mapper copies a to a'; it caches the mapping a -> a',
2. map_fn maps b to a, then the mapper copies a to a''; it caches the mapping b -> a''.

=> Both a' and a'' in output DAG.

@inducer I remembered this morning that I had previously looked into this last fall (and luckily I wrote down all the details in our meeting notes). Back then I decided to set it aside and wait for #515 (after that change map_data_wrapper is no longer creating unnecessary copies, so it avoids the issue). But this time I thought I'd take a quick stab at refactoring deduplicate_data_wrappers anyway. Sticking the previous cached_data_wrapper_if_present implementation into map_data_wrapper should prevent the issue, because it gets rid of the CopyMapper implementation that was creating unnecessary new data wrappers.

With the changes in this PR I'm seeing a small improvement in transform_dag times on prediction (7% or so).

[majosm]

Ready for a look. Any idea what's up with the Doc CI? (Fixed by #586.)