Re-export `os::<platform>::Symbol` from top-level as `RawSymbol`

[mitchmindtree]

Currently, it's not possible to name the underlying raw lifetime-less Symbol type in a cross-platform manner without the user adding some platform-specific compiler flags and re-exporting it from each os module themselves, e.g. something like:

#[cfg(windows)]
use libloading::os::windows::Symbol as RawSymbol;
#[cfg(unix)]
use libloading::os::unix::Symbol as RawSymbol;

The idea behind this PR is to allow users to refer to the type directly as libloading::RawSymbol.

Motivation: I'm currently using libloading in a project where I'm hot-loading a handful of very hot functions. Rather than load the Symbol on every frame I thought I'd load them once and store the raw symbol alongside the Library, though realised the os::platform::Symbol path mentioned in the docs doesn't exist and quickly ran into the issue mentioned above.

@nagisa let me know if something like this sounds OK or if I'm missing something!

[nagisa]

Hi. there was a request to do so in the past in https://github.com/nagisa/rust_libloading/issues/40, and nothing has meaningfully changed since then.

If the goal is to only get access to an implementation that does not enforce the lifetime constraints, then what should be done is another cross-platform wrapper, much like the current Symbol, which only exposes the cross platform APIs. The re-export as is will make it straightforward for the user to start depending on platform-specific code without them or the reviewers of the code noticing they're doing so.

[nagisa]

Some other approaches you could take are: use a Pin, rental or similar ecosystem crate to produce a self-referential structure, or generate code such as what e.g. bindgen generates when asked to produce dynamic loading based bindings: