First step to addons support

**This is a first step to add addons support to Nette, no BC breaks.**

It solves the definition, naming and installation of addons and we can have access to it's directory (for resources, etc.).

Next steps should be:
 - routing to addon's Presenters, loading addon's templates
 - some 'sugar' like addons.neon and some automatic behaviour following suggested conventions

How does it work at the moment?
=====
Every addon is a subclass of `Nette\Addons\Addon`. It has some methods to resolve it's name and path. The compile() function is used to register compiler extensions. The basic approach is similar to Kdyby, but simplified.

1. Addon definition
-----
Every addon must be a subclass of Nette\Addons\Addon.

The simplest addon class can be empty:

	class TestAddon extends Nette\Addons\Addon
	{
		// the default addon name will be resolved from the class name - "test"
	}

The addon's creator can also specify it's default name:

	class TestAddon extends Nette\Addons\Addon
	{
		protected $name = 'someName';
	}

**User of the addon can always overwrite its name (see *installation*).**

We can register compiler extensions in the compile function:

	class TestAddon extends Nette\Addons\Addon
	{
		public function compile(Nette\Config\Configurator $configurator, Nette\Config\Compiler $compiler, AddonContainer $addonContainer)
	{
			$compiler->addExtension($this->name, new TestExtension);
		}
	}

We can also use Nette\Application\Application events in the addon:

	class TestAddon extends Nette\Addons\Addon
	{
		public function startup() {}
		public function request(Nette\Application\Request $request) {}
		public function response(Nette\Application\IResponse $response) {}
		public function error(\Exception $e) {}
		public function shutdown(\Exception $e = NULL) {}
	}

2. Installation (in bootstrap.php)
-----
	$configurator->registerAddons(array(
		new TestAddonPack\ConsoleAddon\ConsoleAddon
	));

Addon can be also named by user:

	$configurator->registerAddons(array(
		'myConsole' => new TestAddonPack\ConsoleAddon\ConsoleAddon
	));

If addon is not named by user, it can have a default name given by it's creator. If there is no one, the addon will take the name from the class name (ConsoleAddon will be "console").

3. Compiler extensions
-----
Compiler extension can be registered in the addon class in a function compile(). The suggested convention is using the addon name as a prefix:

		public function compile(Nette\Config\Configurator $configurator, Nette\Config\Compiler $compiler, AddonContainer $addonContainer)
	{
		$compiler->addExtension("$this->name.one", new OneExtension);
		$compiler->addExtension("$this->name.other", new AnyOtherExtension);
	}

All the service definitions should be named with $this->prefix().

**If we use this conventions, user is able to rename the prefix of addons services as he needs.**
This could, however, bring a problem when we create an addon that refers some services from another addon. To find out the name that user has chosen for addon we can use the AddonContainer:

	$addonContainer->getAddonByType('Vendor\TestAddon\TestAddon')

Inside a compiler extension class we can simply use:

	$name = $this->parameters['addons']['Vendor\TestAddon\TestAddon'];

4. Using addons, AddonManager
-----
Many addons will add it's function to the DI container as a new services - then we can use them as any other services.

If we need to get some information about the addon (name, path, etc.), we can use service `addonManager`. For example in a Presenter class:

	$addon = $this->context->nette->addonManager->getAddon('testAddon');

Or:

	$addon = $this->context->nette->addonManager->getAddonByType('Vendor\TestAddon\TestAddon');

Etc. (See the AddonManager class methods.)

Then we can get desired information:

	$addon->getName();
	$addon->getPath();
	$addon->getNamespace();