[EmuSIMD] Make default `load`/`store` semantics unaligned

[BigUglySpider]

It is fairly unintuitive to expect the user to opt into all instances in which they believe their data will be unaligned, and instead they should opt in when they know it will be aligned.

As such, this suggests the following:

• Abandon the x86 approach (load, loadu, store, storeu for aligned/unaligned loads/stores)
• Change existing loads and stores to used unaligned intrinsics
• Add explicitly opt-in aligned load and store operations
  • Should follow the syntax load, loada, store, storea for unaligned/aligned loads/stores

This has already proven to be an issue with some areas which are unexpectedly segfaulting as a result of the alignment expectation by default.

[BigUglySpider]

Pinning due to high priority.

[BigUglySpider]

As of commit fc5f7dca381b4bdefbc7fc029594221df7506a7c this issue has now been addressed.

Notable info:

• Uses the syntax load/store for unaligned loads/stores, as suggested, but instead of the syntax loada/storea for aligned loads/stores we use aligned_load/aligned_store.
  • Makes things a little more obvious about what you're getting into and makes mistaken aligns/loads less likely due to autocompletion
• Includes templatised aligned_load/aligned_store operations to provide the exact same functionality as before, but now opt-in for aligned expectation
• Current functions that were previously safe with aligned expectations are now using the unaligned variant
  • This is due to the load/store they were calling now being unaligned-by-default
  • No performance lost on test hardware even in the tightest tests that are known to be safely aligned in memory, such as 8K noise texture generation
  • Low priority to update as functionality is as expected with no performance lost
    • Would be a nice-to-have just for the sake of support on hardware that may benefit from the alignment guarantee, but will be done on a case-by-case basis rather than a flat issue