Add initial implementation of a stable API

[ianks]

As part of #227, this PR implements a the basis for a stable ABI for Ruby on Rust. For companies that run ruby-head in production, ABI instability is a serious priority, since without having stability it's hard (if not impossible) to test out certain changes to Ruby.

This can be incredibly disruptive to both Ruby core, as well as Rust gem authors. The goal here is to always Just Work™️ with ruby-head, but without sacrificing performance on stable Ruby.

The core idea consists of two main parts.

1) C Macro + Inline Function Support

In Rust, we don't get access to the suite of Ruby C macros or inline functions in libruby. So we have to either:

• a) implement them by hand (most performant, benefits from rustc inlining, etc)
• b) compile some C glue code to call into (compatible with unstable Ruby ABI like ruby-head)
• c) both

This PR makes it so rb-sys does both, so we get the best of both worlds. On known stable versions of Ruby, we use the hand-written Rust implementations of the Ruby macros. On ruby-head, we use the compiled C glue code.

2) Make internal Ruby data structures opaque

This PR also adds a new stable-abi feature for rb-sys, which will make the internal layout of various Ruby structs opaque (i.e. RString and RArray). With this feature enabled, it will become impossible for upstream crates to have ABI instability when using the opaque struct.

For now, this feature is off by default (with some deprecation warnings) to allow for adoption (with. In v1.0, it will be enabled by default.

[ianks]

Alright, so after thinking on what @matsadler said, I've decided to make the compiled C fallback optional (behind a stable-abi-compiled-fallback feature flag or --cfg=rb_sys_use_stable_api_compiled_fallback). This makes it easy to toggle on when required without risking unintended slowdowns, etc.

With that all said and done, I think this is close to being good to go. Just testing out a few more things on some gems in prod.

[ianks]

The windows failures are unrelated, and will be fixed in #221. Going to go ahead and merge this.

To be clear, this PR adds an opt-in stable-api with the ability to support ruby-head. It adds zero dependencie - in fact, it removes one! Typically, users should interact with the macros that are backed by this stable API (i.e. RSTRING_PTR, etc).

❤️