SIMD support

[djkoloski]

While adding rkyv support to glam, the question came up of how to handle SIMD-optimized types. There are a few pieces here:

• SIMD types should ideally have the same archived and unarchived representations. Otherwise, the same code would be duplicated many more times to support explicitly-endian types like f32_le and i64_be.
• Some types may have different layouts depending on whether SIMD support is enabled. Many SIMD types have higher alignment, for example.
• On-demand endianness conversions (for example, reading an i32_be on a little-endian machine) may have negative performance impacts and should be carefully benchmarked.

With those in mind, let's take a look at the following:

• Can common types like vectors and matrices be parameterized over rend types? For example type Vec2_le = XY<f32_le> and type Vec2_be = XY<f32_be>?
• Should archived types have their alignments artificially raised to the highest common alignment? This may affect packing performance.
• Should SIMD types be archived as more basic data types and only be converted to SIMD types on read? This would be sad for performance but good for sanity. Maybe having a wrapper type to allow for either behavior would be best?

With the concrete goals:

• Determine the best approach for archiving explicitly-endian data with respect to compatibility, ergonomics, code impact, and performance.
• Get some proofs of the concept working with glam and consider looking at other popular vector math libraries like cgmath and uv.
• Perform some benchmarking to figure out the performance story.

[djkoloski]

I don't think this is as valuable as it seemed when it was written. Closing this issue.