plugins

Add apply(String) and apply(Class) to PluginAware.

+review REVIEW-5298

Some changes to detangle some service and DSL objects when applying plugins:

- Added PluginAwareInternal to provide access to the PluginManager for a target object

- Use this in DefaultObjectConfigurationAction to apply plugins using a PluginManager, for `apply plugin: ...` DSL usages.

- Use this in DefaultPluginRequestApplicator to apply plugins using a PluginManager, for `plugins { ... }` DSL usage.

Clean up of API docs for PluginAware and AppliedPlugin.

+review REVIEW-5214

Annotate deprecated methods with @java.lang.Deprecated

+review REVIEW-5239

Imports.

+review REVIEW-5214

Deprecate all mutative methods of PluginContainer

+review REVIEW-5239

Add PluginAware(Action).

+review REVIEW-5214

Make withId(), hasPlugin() etc. work for qualified and unqualified “privileged” names regardless of how the plugin was applied.

+review REVIEW-5214

Deprecate PluginContainer.apply(Class) and PluginContainer.apply(String)

+review REVIEW-5239

Collapse AppliedPlugins into PluginAware.

+review REVIEW-5214

Improvements to dealing with ID-less plugins and general polishing.

+review REVIEW-5214

Centralise detection/handling of different types of plugins.

+review REVIEW-5214

Add ability to query for plugins and rule sources by id

+review REVIEW-5214

Intorduce PluginAwareInternal and AppliedPlugins interfaces

+review REVIEW-5214

Change: Correct some misspelling and duplicate words

Improve error messages when a plugin fails to apply.

+review REVIEW-5046

use link instead of code tag.

Fixed type signature.

Changed object decoration so that properties are not defined on assignment. This behaviour was deprecated.

Fix generic signature.

Removed deprecated ExtensionContainer.add() method.

Remove unnecessary closure overload method.

Added plugins.withId("pluginId") api for filtering plugins by id.

Needs review because I've used Closure type for method parameters. I've been following the pattern we already have for the PluginContainer. Can we start decorating the PluginContainer? Is it a breaking change? If so, let's do it in 2.0.

The api needs general review (e.g. return types, generic types, etc.)

Moved some internal classes out of org.gradle.api.internal to live under org.gradle.internal

Remove @author tags and names from source code.

- Added checkstyle check for @author

- Added not to CONTRIBUTING.md saying that we don't use names in the codebase

GRADLE-2066: Extract PluginAware interface out of Project.