ToolChain is no longer an axis in the dimensions of a binary variant
   - Don't create a binary variant for every available tool chain
   - Create a binary variant for each target platform, and find a tool chain that can build for that platform
   - By default, add a single tool chain for each registered type, rather than just the first available.
Move configuration of the set of available platforms into model rules

- Currently our configuration infrastructure doesn't properly handle NamedDomainObjectContainer, so use explicit 'create' calls to add platform
Delete configuration action that has been replace by a model rule
Don't include tool chain name in binary name
Allow a component to target a set of platforms, rather than all defined platforms.
Update build type configuration to use model rules and allow a component to target a particular build type
Reworked configuration of native binary flavors to be consistent with platform and buildType

- Define a set of flavors in the FlavorContainer as part of model
- By default, a component will be built for all defined flavours
- A component may specify a subset of flavors that should be built
- NOTE: resolving dependencies now requires an exact match by flavor
   - The plan is to fix this with real dependency resolution
Add convenience to choose all 'matching' buildType/platform/flavor instances for a component
Allow multiple selectors to be provided to a component for platform and buildType
Checkstyle fix
Added story for targeting a component to subset of buildTypes, flavors and platforms
Renames for consistency on NativeComponent
- buildTypes -> targetBuildTypes
- flavours -> targetFlavors

I don't really love these new names but I like the consistency. My preferred DSL
is "component.target flavors.foo" and "component.target buildTypes.debug, buildTypes.release". Need to push more stuff in the model rules to make this possible.