I just noticed a sort of conceptual error in the current bank file format.

Right now, things like `router_rules`, `cc`, and `cc_links` can be defined either inside an individual patch or at the bank level. Bank-level settings are applied first, followed by the settings for the selected patch. This works nicely for things that should be common to every patch—for example, sending volume and reverb controls to all of the channels—but there's a problem: sometimes I want to send a MIDI message **once**, when the bank is loaded, rather than every time a patch is selected.

`fluidsettings` already work this way: they're defined at the bank level and applied when the bank is loaded. But the other bank-level keywords are really acting more like defaults for every patch, which makes the two concepts a little muddled.

My first thought is to add another level inside `patches`: something that isn't a patch itself, but contains settings that get applied whenever a new patch is selected. Bank-level settings would then happen once when the bank loads, these intermediate settings would happen whenever a patch is selected, and individual patch settings would be applied on top of those. That seems more logical, and would give me another useful level of configuration.

The more I poke at the code, though, the more I realize I don't actually need to restructure the bank hierarchy. There can't be arbitrary keywords directly inside `patches:` because they'd potentially collide with patch names, and most of these settings need to be cleared and re-processed whenever a new patch is selected anyway. Really, the only things that benefit from a "do this once when the bank loads" operation are `cc` and `sysex`.

So the solution is much simpler: I'm adding a bank-level **`init` keyword**. Anything under `init` gets processed once when the bank is loaded, while the existing behavior of the other settings stays intact.

I started out thinking I needed to redesign the bank format and risk breaking existing files, and ended up adding one keyword. That's considerably better. Sometimes the best solution is to spend a few days convincing yourself not to implement the complicated one.