Added allocator-api2 for stable support

[H4n-uL]

Replaced #![feature(allocator_api)] with allocator-api2 crate to enable building on stable channel

[IsaacWoods]

Hi, thanks for the PR.

Generally, I am against these shim crates that reimplement parts of the standard library that are yet to be stabilised. In its current form (I think from the docs for allocator-api2 it could be made compatible with both nightly/stable toolchains with a bunch of cfgd re-exports) this PR would create breaking changes both on merge and then require more breaking changes to hopefully remove it if the allocator API does stabilise.

I have not looked re the state of the ecosystem - is there consensus that the library used is the de-facto stand-in for this feature until it's merged? I note there is a allocator_api crate that has been updated more recently with what looks like similar contents? I feel these "solutions" can become unmaintained quickly.

Do you have a project / usecase for this crate that requires a stable toolchain to be used / all other components can be built without nightly features? My personal OS work has required numerous unstable features, although admittedly I'm probably behind on what has been stabilised recently.

If this is required, this PR would need to be refactored to have no breakage for users utilising the real unstable alloc types, and the diff will need to be acceptable in how it deals with the types.