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 #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: