Plugin architecture broken

[theangryangel]

Current plugin architecture does not easily permit per-connection settings or multiple instances of the same plugin, without the plugin having to resort to managing it's own settings in an overly complex manner.

i.e. 2 instances of livemap running on different ports, or multiple versions of a track rotation plugin with different sets of stuff.

Proposed fix:
Plugins should return a function object that a new object can be created for each set of settings.

Pros:

• Each plugin automatically gets it's own space to save state and options
• Plugins can still be associated with multiple connections

Cons:

• Requires all plugins to be updated
• Plugins become more difficult to write

[theangryangel]

fcbceac introduces the new simplified API.

Each plugin must return a class that can be created as an instance (i.e. via module.exports). Each class must follow the following prototype:
var plugin = function(options)
{
// setup options
}
plugin.prototype.associate = function(client)
{
// associates this plugin instance with client
// here you can setup event listeners, etc.
// events emitted by the client no longer have a custom scope, and now have the default scope for eventemitter (the client)
}