GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * must be activated thanks to a type checking extension
   * makeDynamic(call) would turn an unresolved method call into a dynamic method call
   * makeDynamic(call, classNode) would turn an unresolved method call into a dynamic method call returning an object of the classNode type
   * makeDynamic(propertyExpr) would turn an unresolved property into a dynamic property lookup
   * makeDynamic(propertyExpr, classNode) would turn an unresolved property into a dynamic property lookup returning an object of the classNode type
   * makeDynamic(variableExpr) would turn an unresolved variable into a dynamic variable lookup
   * makeDynamic(variableExpr, classNode) would turn an unresolved variable into a dynamic variable lookup returning an object of the classNode type
   * makeDynamic automatically suppresses type checking errors by setting the handled=true flag to true
   * for method calls, makeDynamic returns a dummy MethodNode, allowing to suppress the type checking error

It is expected that the extension writer provided appropriate return types.
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * make sure Foo.metaClass.bar = {...} can be handled through an extension
   * add buildListType(componentType) and buildMapType(keyType,valueType) for lists/maps (helper method)
   * add isStaticMethodCallOnClass helper method for easier detection of static method calls on a specific receiver type
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * refactored isStaticMethodCallOnReceiver into two distinct methods
   * introduced extractStaticReceiver(methodCall) for that purpose
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * fixed dynamic method calls if made inside a closure
   * add a unit test/example on how to deal with builders
Merge branch 'compilestatic_mixedmode'
Bintray JCenter added as a first resolver in the default Ivy chain.
The resolution should be much faster now: this repo is much faster than the former first resolver (codehaus) and it contains most of the content from most of the popular Java repositories, which means most of the artifacts will be resolved without trying other repositories in the chain.
GROOVY-6379: Wrong example in the api of class Map(dropWhile)
GROOVY-6372: @Immutable fails to recognize non immutable classes (move the simple cases of matching on classname whitelist from runtime to compile time)
GROOVY-6384: add a direct method call logic for Class.forName(x)
GROOVY-6380: Improve Grapes resolution speed and stability by adding Bintray JCenter as first remote resolver in the chain

moved defaultGrapeConfig.xml for tests to correct test resource directory
Improve the grammar of a compiler error message
Merge pull request #263 from jeffbrown/errormessage

Improve the grammar of a compiler error message
update copyright year
removed outdated comment
GROOVY-6385: groovy.bat: Can't use question mark in script parameters

As suggested by Dominique on the mailing list:

http://groovy.329449.n5.nabble.com/Can-t-use-question-mark-in-script-parameters-td5716658.html
Fix for GROOVY-6386 - groovyc task throws ZipException when it
encounters classpath resources that are not jars.
Revert "Improve the grammar of a compiler error message"

This reverts commit 21610e630a5567c64873c4790eee5a1387aa4337.
activated "testIteratingWithList" test
Revert "Revert "Improve the grammar of a compiler error message""

This reverts commit ad6d1e274ad547e56452861e3a1a01936f02d00a.

I did not want to revert the "Improve the grammar of a compiler error message" commit, so I reverted the revert.
reactivated some tests