Implement load-time initialisation

[PyPylia]

Currently, maybe_special only utilises compile-time and run-time (specifically upon first run of a function) dispatch initialisation.

Implementing load-time initialisation, such as with LLVM IFUNCs, would allow for the performance impact of initialisation to be moved to load-time, rather than at run-time, which seems like a better option. LLVM IFUNCs specifically have the issue that it seems like it'd need support from rustc itself to work, which doesn't currently exist as far as I'm aware.

Additionally, this may allow for better optimised code, as currently each individual initialisation function must make many calls to the is_*_feature_detected macros, which are currently quite slow for reasons documented in this thread (the detected features are cached by these macros, but LLVM does not seem to always optimise successive relaxed atomic reads, which is needed by maybe_special for fine-grained feature detection). By moving all initialisation to load-time, the initialisation functions could possibly be combined in some way to partially mitigate this issue.

It is also possible to do this via a global initialisation function called at the start of main (although I don't currently know the details of how that'd work), but that introduces its own issues, such as how to deal with situations where the user forgets to call that function. It may also be possible to direct every initialisation function to a global init function, but again that is complicated, and could cause unexpected lag spikes upon the first call of any specialised function.

Finally, all of this is complicated by the fact I wish to maintain support for all architectures and operating systems. I am currently reliant on std_detect for feature detection, which I am okay with, as it seems to be the best supported feature detection crate (and as such any feature detection issues with this crate should be directed there instead), and I do have a fallback for unsupported systems. Adding additional features that would only be beneficial to a limited number of operating systems and architectures is out of scope for what I am currently aiming to implement, but I will happily accept any PR that does this so long as there are no regressions for other systems.

[PyPylia]

Looking deeper into this recently, and if I take some ideas from ctor and linkme I should be able to implement this merely with some linker shenanigans. The best way to handle this is probably to have a global initialisation function that is marked as the ctor link section and as inline never, then retain every initialisation function but only just to call that global initialiser. These function-specific initialisation functions shouldn't ever be called, but prevent UB in the circumstance that the dynamic linker does not call the global initialiser in return for an extreme performance impact upon first call of any specialised function.

This can potentially still introduce UB in the situation the executable has been passed through a pre-intialiser, and as such it would be best if this load-time initialisation is feature-gated with a warning in the README and docs. To maintain a global initialiser across all modules that use the macro, I would also likely have to split this up into a proc-macro and normal crate (to hold the global initialiser to prevent duplication). This doesn't completely eliminate duplicate global initialisers in the event that multiple crates in the build path use different versions of this library, but does help.

Additionally, until a workaround for #3 is figured out, the global initialisation function would likely involve many redundant reads as each feature would have to queried from the feature cache individually. Manually implementing feature querying via reading the auxiliary vector (or equivalent on Windows) is possible, but would be a huge undertaking and would only be applicable for UNIX-based systems (and Windows if it's equivalent is implemented). Additionally, it may be impossible to query the auxiliary vector if environ has been tampered with, and as Rust makes no guarantees on the state of the program prior to main executing, this is possible. Querying CPU features via other means would be an unreasonable load to take on for this tiny library, so I believe it would be better to simply hope std_detect implements a means to bulk query features.