Brainstorm: Publish to crates.io

In this incomplete branch I tried to publish librsvg_crate to crates.io. Asking on the users forum produced some interesting advice:

• Either we publish rsvg_internals as a "don't use directly crate"...
• ... or we fold everything into a single crate, perhaps with conditional compilation to disable the C API for a Rust-only build.

Terminology:

• rsvg_internals - Implementation of the library, with entry points in handle.rs
• librsvg_crate - "new and hard to misuse" public Rust API, a thin wrapper over most entry points in rsvg_internals
• librsvg - C API with all its idiosyncrasies and Glib-isms.

The C API could be fully implemented in terms of the librsvg_crate API, except for the quirky get_geometry_sub().

As a special detail of the (still C-based) test suite, we need rsvg_handle_internal_set_testing(); the librsvg_crate API doesn't expose that.

For publishing to crates.io, perhaps we'll need to fold everything together again. This is not terrible, now that there is a clear separation of special stuff for the C API, and the Rust stuff.

Adding some conditional compilation to for the C API stuff would have the (undesirable?) side effect of requiring two builds during CI, one for the pure Rust API, and one for the C API (and maybe the test suite).

However, one nice effect of !398 (merged) is that even if we do two builds, they will be much faster than before. So, the scheme where we had to have separate crates to have reasonable build times may no longer be a concern.

#427 (closed) is about porting the test suite to Rust; this would have to be done in a separate crate, since crates.io has a 10 MB limit. This is fine; we can still use a Cargo workspace as usual.