Major refactoring of the CLI

A much needed major refactoring of the CLI (basically the guts of GradleFx) to make GradleFx easier to maintain:

* upgrade to groovy 2.3.3 (mostly for Trait support)
* upgrade to Gradle 2.0
* re-introduction of the frameworkLinkage.none property to support pure AS projects using the Flex SDK, which now shouldn't be such a burden on the code with this refactor
* split up all the common compiler option manipulations into "option injectors", which can then be composed in the compiler instruction cookbooks
* Extracted the compiler process itself from the CommandLineInstruction class to a CompilerProcess class
* Introduction of compiler instruction "cookbooks", which define what needs to happen for a specific type of application/library. This removes the complex if-else blocks and makes each cookbook focused on one type of application/library.
* Which cookbook that is used is determined in the Mxmlc/Compc/Test tasks. From now on this should be the only place with if/else blocks. These if/else blocks are easy to understand since they simply select a cookbook, nothing more. This keeps the complexity out of the guts of GradleFx.

Basically, it keeps all the old projects working while also providing all the new features of @matyasatfp PR. It should now be much easier to determine what exactly happens (in terms of compiler option logic) for each type of project, since almost each type has now its own compiler instruction cookbook, which simply is a listing of what needs to happen. This is achieved with Trait composition.

I've tested this against @matyasatfp sample ios-mobile project (located matyasatfp/GradleFx-Examples@1778c31), which will now (with some modifications) also be integrated into the GradleFx-testbed project for regression testing. Tasks that were executed: 'compile', 'test', 'flashbuilder', 'idea' (not package, since I don't have a provisioning file or certificate)

@RIAstar @matyasatfp if you guys have time, feel free to review
Why not use the latest Gradle (2.2.1)? would it need lots of refactoring?