Merge simd vector traits

[ejmahler]

Closes #188

SseNum, NeonNum, etc are gone. SseVector, NeonVector, etc have been merged into SimdVector, so now it's just the one trait (with one minor exception).

SSE and Neon went smoothly. When I converted wasm simd and fcma, I found that they bounced too freely between the wrapped types and the bare metal types, and it made it difficult to apply simple find and replace type operations. I ended up converting them both to use the wrapper in all places. That was quite painful, but hopefully it will pay off in the form of reduced tech debt.

I also eliminated the per-architecture array traits, and replaced them with a generic trait called SimdComplexArray and SimdComplexArrayMut. I redid some of the naming conventions while I was in here, mainly to reduce wordiness of common operations.

I ended up keeping the FcmaVector trait, but it only has the rotate_and_add etc methods that are unique to fcma. There's one more thing to resolve here, which is that I put unimplemented!() on the fcma apply_rotate90 and nmadd methods. They're only used by butterflies and will never be used by generic code, so I'm questioning whether they belong in the SimdVector trait at all. In the case of fcma, the reason i paid attention to it is because if you call apply_rotate90 you're probably leaving performance on the table and should probably be calling something that leads to fcma instructions and applying the rotations that way.

It would be fine to just check it in how it is as a little tech debt thing, but I'll sleep on it and see if I come up with a decision for how to handle it.

[ejmahler]

One more thing that could be done here: We have macros in each of the architectures to make it easier for the butterflies to load big chunks of data, with different strides etc, and they're all identical, so they could be combined too.

[ejmahler]

I decided not to do anything on either front for now.

For the macros, there's more refactoring I want to do here - for example, these could be methods on SimdComplexArrayMut, at least some of them. But until then, they're not doing any harm sitting where they are.

For the trait, the only math ops that need to go in the SimdVector traits are the ones needed by the generic algorithms. Mostly that's just mul_complex, but a hypothetical SimdRadersAlgorthim would need an add(), and a conjugate or multiply-and-conjugate. I'd argue for even removing make_rotation, apply_rotation, and the rotation associated type, and instead introduciong a butterfly4 opaque type.

The reason why I'm not doing this now is that I'm cooking up a longer term plan for how to arrange these non-generic math operations. The main benefit of having a math op in the trait is to make it generic over f32 and f64. If a math op is only used by butterflies, we're not using that feature at all, so why pay for it? With the status quo it doesn't matter either way, which is why they're inside of traits. But if we move math ops out of the trait, they can be marked with target_feature. So if we move the butterfly-only math ops out of traits, that plus const generic array operations could pave the way towards our simd butterflies being 100% safe.

That's obviously a completely unrelated task to this, so I'm just going to leave SimdVector how it is for now.