cdylib: symbol versioning

[cyphar]

In order to avoid compatibility issues in the future, we should make use of symbol versioning from the first release in order to avoid having to bump the SONAME when we eventually run into an incompatible change.

There are a few issues to note (I haven't tested these yet, I'm just collecting my notes from reading about this for a bit):

1. Rust appears to specify its own version map (though it seems that this isn't the case for panic="abort"?) which means some magic is necessary to use our version map for our own symbols. It also appears to include our symbols in its default version map, so you also need to define the symbols with alternative names and then use -Wl,--defsym=foo=foo_impl to remap them. This will probably cause issues with cbindgen...
   • https://users.rust-lang.org/t/how-to-use-linker-version-scripts-in-rust-1-54/64033
   • https://users.rust-lang.org/t/hiding-rust-eh-personality-symbol-in-cdylib/60490
2. There is no way to do asm(".symver ...")/__attribute__(symver()) in Rust at the moment, so if we ever end up having the same symbol name in two different versions (ie. there was an incompatible semantics change for a function and we want new programs to not use the function) it might not be possible to generate a version map with the right symbols. I suspect that --defsym=... can't be used for this purpose but we might want to look into that.
   • https://internals.rust-lang.org/t/support-symbolversioning-in-export-name/15021

I suspect defining a version map from the outset even if we don't know how to deal with (2) is probably a good idea.

[cyphar]

Duplicate of #12, but I'll migrate that here.

Right now we don't have any kind of real versioning in the C API. It would be nice to have symbol versioning (this post has some interesting advice), and probably also some kind of pathrs_version() function which gives you the version of libpathrs you're dealing with.