Add a `new_mapped` method

[gretchenfrage]

Hi! I totally understand if the slab project is hesitant to add a somewhat "unconventional" feature such as this, but I heavily use it in a project of mine via a patched fork of slab and so I thought I'd open an upstream PR for consideration.

Basically the use case for this is that in various places I use slabs to manage the index space for something which many of can be created or destroyed. For example, there is a server in which at any moment there is a set of distinct "Foos", and various pieces of state is associated with each "Foo." I can store each piece of per-Foo state in a slab of that state type, such that when creating or destroying a "Foo," I first add or remove the entry in a single slab that I consider the "main slab" that manages the space of "Foos," and then immediately follow that by performing an equivalent addition or removal to all other per-"Foo" slabs to keep them synchronized. Debug-asserting that the main slab and follower slabs return the same index upon insertions helps detect de-synchronization bugs.

There are various advantages to this pattern, including it being a nice compromise of speed and fail-fastness, making things more modular and cache-local by splitting up state, and by having the "main" slab for some space on one machine and some follower slabs on different networked machines and considering index-mismatches a protocol violation then I can avoid the cost of hash table lookups while constraining the possibility space of denial of service attacks.

In any case, in that pattern, this new_mapped function is important for cases where per-"Foo" slabs are being created and destroyed dynamically. For example, possibly I have both a space of "Foos" and a space of "Bars," and for each "Bar," for each "Foo," I maintain some state for that "Bar"/"Foo" combination, thus forming a doubly nested matrix of slabs. In that case, it's important to be able to construct a new slab which's internal vacant/free-tracking structures are equivalent to those of an existing slab, but which has different data and possibly a different data type than the existing slab.

I'm aware that at points there have been discussions of potentially changing the internal / external architecture of slab (eg #46). Wanting to keep that possibility open would be in tension with a feature like this which moves more in a direction of exposing more of its internal structure as an API contract. However, my impression is that by this point slab is probably pretty stable and unlikely to change in such ways.

If you're interested in something like this but think new_mapped is too fixed, potentially we could explore more low-level mechanisms for making something like this happen. However I'm not sure how best to do that without creating an over-complicated feature.

Thanks for your consideration.