Define initial plugin standard

[montlebalm]

As an F2 developer, I want to know how plugins work, so I can extend the library in a supported fashion.

Currently plugins exist as an idea in F2. We've talked about writing them and have loosely described how they might be achieved. I think it's time to start thinking about what they actually look like and how developers should be allowed to extend the library.

1. No formal system

The simplest way of extending the library is to add to or replace the API directly. For instance, any developer can write:

F2.UI.Modals.alert = function(message, callback) {
  // Custom modal
}

This approach doesn't require any code changes on our part. We'd be leaving it up to each plugin developer to choose their own implementation.

When F2 is on the window, plugins can target it easily on load. However, sites that use a module system like AMD or CommonJS will need to pass an F2 reference to the plugin.

2. Exposed config

An alternative to the wild wild west approach above is to specify which pieces of the library we approve of replacing. This could be achieved during F2's instantiation. For instance:

F2.init({
  ui: {
    alert: function(message, callback) {
      // Custom modal
    }
  }
});

This would require some work on our part, but would make it clear which parts of the library are meant to be extended.

Which method do we prefer? Do use 1 for new functionality and 2 to replace existing methods? We should consider our options and test our decision out on #209.

[markhealey]

If we need an established convention, remember No. 2 above ("Exposed Config") is how F2 handles it currently. See F2.ContainerConfig. Also need to review #121.