Add an "allocator-api2" feature

[TDecking]

Second attempt at creating custom allocators for SmallVec.

This one uses the allocator-api2 crate (enabled by the feature with the same name) to provide provide access
to allocators in stable Rust. If the feature is disabled, the allocator api provided by nightly Rust is used instead.

Closes #55.

[alejandro-vaz]

CI is crying

[alejandro-vaz]

this looks good

it's +500 LOC more but it's expected given the feature it's adding

is it now ready for review??

[alejandro-vaz]

I'm not sure how this will interact with your original PR

on one side we have the nightly allocator API

on the other side we have the allocator-api2, which is a reflection of the nightly API ported to stable

this is more complex than I initially thought it to be

we basically have these cases:

• stable + no allocator
• stable + allocator-api2
• nightly + no allocator
• nightly + allocator-api
• nightly + allocator-api2

but since api2 is just api re-exported, this is simply a normal feature that works when enabled independently of the rust build

and since api2 re-exports api, we can simply never link against the unstable allocator-api and use allocator-api2. that will also help us by removing a potential version mismatch between allocator-api2 and the current nightly implementation

regarding the implementations, I think we should go dead-simple: use an allocator generic internally for SmallVec and RawSmallVec (not sure but I think it'd be necessary). and if the feature is disabled, then we export SmallVec with the last type argument being Global

let me know your opinion on this

[TDecking]

The first PR can be closed now. It was an attempt to get the "stable + no allocator" and "nightly + allocator-api" under one hood without any dependency. It worked, but it was also ugly. I've opted to create a new PR for supporting allocator-api2 since it would mean a complete rewrite anyway and also as a refresher; I didn't look at the library for several months.

Of all the cases you've listed, "stable + no allocator" and "nightly + no allocator" should be of no concern, because the allocator type variable defaults to Global if not specified. SmallVec<T, N> can be used either way. This should correspond to the "dead-simple" approach you suggested.

allocator-api2 is unfortunately not a simple re-export allocator-api except for the stable parts (Layout, AllocError).
Any change in the nightly Rust API (this PR was hit by one) will mean that this crate needs to support two APIs until
allocator-api2 updates. This is hopefully a surmountable problem.
The way you framed it suggest that you propose to support only allocator-api2. Is that right?

Something that needs to be mentioned is that rust-lang/rust#156882 seems to landing soon (?),
which would open up another option: Unconditionally support custom allocators at the expense of supporting only one Rust version. allocator-api2 promises to just re-rexport std allocation methods once they are stable, the dependency can then be removed.

[alejandro-vaz]

this is becoming insanely complicated

out of all options we have, knowing what you just said that it's almost stabilizing, I'm simply say it's better to wait and implement it properly for the few versions that have it stable

the nightly feature + allocator-api2 setup is just too cumbersome, and having allocator-api2 in the dependency graph certainly isn't nice, it's kind of a smell

we still have a few more months to figure this out, if by the time beta.1 release date approaches (12th October) we see it better, then we implement it in alpha, otherwise we'll have it in beta

we could also try to postpone a bit the releases. say, 9th November beta.1 and 15th December rc.1 or something like that