A simpler representation of an axis location?

## the problem

Currently we store axis locations (in both fea-rs and in fontc) as some sort of map (hash or b-tree) of tag->value. In the font binary, these end up stored as a (sparse) array of values, in axis-order.

I'm finding our current representation a bit difficult to work with, and I'm wondering if there would be some benefit to using a representation closer to what ends up in the binary. The idea would be that we have a `Location` type that is always normalized and is internally stored as `Vec`, and then we enforce that these can only be constructed if you have an `AxisOrdering` (or something) type, which enforces the invariant that the length of the vector equals the number of axes, and they are in the correct order.

### benefits

I think this has a number of benefits:
- we don't need to worry about `OrderedFloat`
- we only need to validate/construct once, and conversion to the final representation is trivial
- storing locations uses less memory (definitely, no storing tags)
- we're probably computationally more efficient, since computers love arrays (not sure how significant this is, but if we're doing tons of hashing it could be relevant)
- we don't have to worry as much about the possibility of an unexpected tag or similar, since we're 'valid by construction'

I'm writing this up right now because I'm running into some annoyances in moving to using f32 instead of Fixed, and it's making me revisit some older design ideas I've had. This doesn't need to block the f32 changes; it's more a longer-term evolution idea.

### drawbacks

It's possible that there are drawbacks here that I'm not considering?
- maybe we want to construct locations in places where we do not have access to the axis order?
- maybe there are implementation challenges to implementing the constructor that I'm not thinking about (what does this API actually look like, how does this work in an avar2 world, etc)

in any case, I think this would likely be at least worth investigating.