Logic system supporting auto plugins and initial outline of AutoPlugin and Natures types.

 * Not integrated into project loading
 * Doesn't yet check that negation is acyclic before execution
Main part of integrating natures into project loading.
API documentation and comments related to natures
logic system/auto-plugins: Provide deprecated methods for binary compatibility
Discover all sbt-related modules (not just Plugin) and write names to resources for use from binaries.
Test for automatic handling of AutoImport, AutoPlugin, and Build from binary plugins.
Acyclic negation checking in logic system that backs auto-plugins.
Translate errors from logic system to Natures system.
API docs, better terminology for negative cycle checking in logic system.
Convert logic system test cases into unit tests.

Still TODO for auto-plugins/logic:

 * property-based tests for logic system
 * user documentation
 * (optional) 'about plugins' or similar to show more information about the auto-plugins for a project
 * (deferred) allow AutoPlugin to inject Commands directly?
 * (deferred) provide AutoPlugin functionality to arbitrary scopes instead of just at the Project level?
Fix typos in AutoPlugin API docs.
minor API updates
Generate error when multiple AutoPlugins provide the same Nature.
move Nature-related classes to Natures.scala
TODO
Restructure Natures/AutoPlugin types

- remove AutoPlugin.provides
 * name comes from module name
 * AutoPlugin is Nature-like via Basic
- Project.addNatures only accepts varags of Nature values
 * enforces that a user cannot explicitly enable an AutoPlugin
 * drops need for && and - combinators
- Project.excludeNatures accepts varags of AutoPlugin values
 * enforces that only AutoPlugins can be excluded
 * drops need for && and - combinators
Infrastructure for debugging natures and plugins.

* Can provide suggestions for how to define a plugin given a context (a loaded Project in practice).
* When a user requests an undefined key at the command line, can indicate whether any (deactivated) plugins provide the key.

TODO:
* Hook up to the key parser
* Implement 'help <plugin>'
* Determine how to best provide the context (the current project is often an aggregating root, which is not typically a useful context)
Make BuildDependencies construction a proper function outside of the settings sytem.
'plugins' and 'plugin <name>' commands to inspect plugins

* 'plugins' displays the list of plugins available for each build along with the project IDs each is enabled on
* 'plugin <name>' displays information about a specific plugin in the context of the current project
 - if the plugin is activated on the current project and if so, information about the keys/configurations it provides
 - how the plugin could be activated if possible
* tries to detect when it is run on an aggregating project and adjusts accordingly
 - indicates if an aggregated project has the plugin activated
 - indicates to change to the specific project to get the right context

This is a rough implementation and needs lots of polishing and deduplicating.
The help for the commands needs to be added/expanded.
Merge pull request #1130 from sbt/wip/auto-plugins

AUTO PLUGIN FEATURE!!!!