Reconsider Dispatcher registry mechanism

[andrewkaufman]

We're not sure about the dispatcher registry mechanism storing shared Dispatcher instances rather than creation functions.

• It's out of keeping with our other registries
• A shared dispatcher isn't very useful for API use, because you have to reset every single setting to know that you'll get what you want - because you never know what the previous use was. This was mentioned before with regard to the test cases, where you've got a logical spot to do the reset, but in other use cases there's not a convenient place to do a reset - just making a new one is the easiest.

[andrewkaufman]

Once #1038 is fixed via #1045, we will have user defaults for plugs, and we can reconsider the Dispatcher registry mechanism again. The objection to registering creators rather than instances was that it prevented startup files from collaborating, each changing only some settings. Now, each file can set some user defaults, but not others, and we get the collaboration we want.

[andrewkaufman]

When we make this change, we should also add setDefaultDispatcher()/getDefaultDispatcher() methods, and make sure DispatcherWindow manages it's own copy of the Dispatchers it needs.

[andrewkaufman]

So, I was merrily going about this and I ran into another issue. We iterate through the existing dispatchers during setupPlugs(). Should this now iterate through the creators, create a new dispatcher of each type, call doSetupPlugs(), then destroy the dispatcher? Or should we instead make doSetupPlugs() static and have some way of locating the class from the registry without actually creating one?

[andrewkaufman]

I know we discussed re-thinking setupPlugs() in #915, but I'd like to avoid that for now if at all possible...