Allow parameters to override config order

[kalekundert]

Right now, the order in which the configs are queried is fully determined at the class-level, by the __config__ attribute. However, the Key() syntax (see #3) makes it natural for each parameter to specify it's own order. There are times where it is necessary to do this. The order of the __config__ attribute also affects the order in which the configs are loaded, and therefore which parameters are available to them at load-time. This does not always correspond with the priority that each config should have when determining specific parameters.

While I'm at it, I will also remove the parameter(key=...) argument, and with it the ability to specify keys using a dictionary. The List[str] syntax handles the simplest cases, and the List[Key] syntax handles everything else. Both are pretty succinct. The Dict[Config, str] syntax doesn't really have a niche anymore.

This feature will require changing the key_map data structure again. Currently, it is:

{Config: [(key, cast)]}

Now, it can simply be:

[(Config, key, cast)]

Note that this is not quite the same as the Key class, because the Config items are instances rather than classes. If I go further and make iter_values() responsible for associating Config classes with Config instances, then I can reuse the Key class:

[Key]

A side benefit of this change is that Config instances won't have to be hashable anymore. That always felt like a leaky abstraction.

[kalekundert]

Note: it turns out to not make sense to have iter_values() responsible for associating Config classes with Config instances. This basically would require providing iter_values() with a bunch of information that it really shouldn't have. So I didn't take that approach.