Remove petitset dependency

[alice-i-cecile]

While this set / map crate is well-suited to our needs in several ways, it's not ideal as:

1. The vector based approach in InputMap is hard to translate to a trait-based approach (UserInput as trait #346), or extend to nested or dynamic actions.
2. The UserInput's memory footprint is hilariously large, as it must store an array-like type.
3. petitset is a nonstandard (if small) dependency.

This PR explores replacing it completely, using HashMaps (currently a MultiMap).

There are several drawbacks to this however:

1. We cannot store a HashSet in our Chord variant, as it is not itself hash.
2. We cannot use a BTreeSet either, as the stored types aren't Ord.
3. As a result, Chord has to store a simple Vec (or array), losing its uniqueness checks.
4. It becomes quite hard to reason about "what is keybinding 2 for this action" in the classical key bindings menu way. Supporting this requires storing either a HashMap<A, Vec<Option<UserInput>> in our input maps (😩) or an explicit slot-like design with a fixed number of possible bindings.

Open Questions

1. Do we keep petitset, and use it only for chords? This allows us to retain uniqueness guarantees but doesn't help our memory footprint.
2. How do we solve the "input binding menu" problem?
   a) Give up, this is a dumb thing to try and model, it should be built into your menu logic not the input map.
   b) Store a map of maps
   c) Store an array of maps
   d) Store each map as a different field
   e) Abandon this PR completely

[sixfold-origami]

For the input binding menu, I think it's ok to let that fire burn for now. This always struck me as more of a menu logic thing anyway, not really an input mapping problem. We may be proven wrong in the future, but I'm not too worried for the time being.

[sixfold-origami]

I also think it's ok that chords are stored as Vecs. We should probably make sure there's a docs warning for this (namely that uniqueness it not checked), but I think it's ok.

[alice-i-cecile]

Conclusion on the design questions above:

1. We just use a Vec, and enforce uniqueness on the constructor.
2. Choose solution a. I've cut the input binding menu example as part of this PR, and opened Add a key binding example #403 for a replacement to avoid blocking this work.

[100-TomatoJuice]

Restating here for documentation. The failures are due to A::variants(), I think.

With an enum like this:

#[derive(Actionlike, PartialEq, Eq, Clone, Copy, Hash, Debug, Reflect)]
enum AxislikeTestAction {
    X,
    Y,
    XY,
}

It only checks the variant X. This happens in .which_pressed() on InputMap. The for loop that loops through A::variants() only loops once: not doing anything the other two variants. But, the examples return all variants? I'm now looking for the cause of the A::variants() only returning one.

For this enum, I added inputs for Jump and Run, but not A.

enum Action {
    Jump,
    A,
    Run,
}

The result was Jump worked but Run did not as A blocked of any lower actions for some reason.

[100-TomatoJuice]

There are still quite a bit of A::variants() usage left. I'm kinda surprised that it has not broken anything else like it did. Is it within the scope of this pr to remove usage of A::variants() as you mentioned on Discord? The removal of A::variants() will not be trivial, I think. For InputMap it can use iter(), but ActionState doesn't have access to the map so it will require some thought.

[alice-i-cecile]

Let's pull that out into a separate PR and merge this now :)