As far as I can tell, there was no way previously for an application
to register a plugin and ensure that plugin got loaded -- it would
be necessary to manually edit the config and specify the plugin be
loaded.

This is suboptimal; if third party code wishes to track third party
extensions on the blockchain, the correct way to do this is with a
plugin, and this third party build should be able to load these
required plugins regardless of whether the config lists them or not.

This commit adds a boolean parameter to application::register_plugin
which defaults to false for backwards compatibility; however, if
set to true, the plugin will automatically be enabled when the app
initializes.

That code was nasty and... kinda wrong. So fix it up all shiny-like.

But I also removed the super annoying default "wanted" plugins list,
which only causes problems for third parties like me, and in general is
just poor form. In my opinion, 5220425
provides a much cleaner way to do this, in a way that is friendly rather
than hostile to third parties.

Would Be Nice: A generalized plugin conflict system added at the
abstract_plugin level, so, for example, the elasticsearch plugin can
conflict account_history and we deal with this in a general fashion
rather than having this dirty special case check here.

…tshares-core into pull1427_2