fixes JOO-82
EXML XSD generator fails in directories under a symlink
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-82

The bug is caused by checks whether a file found in the source
path is actually a generated file, which are implemented by
checking whether the source file is below the output folder.
These checks become obsolete with the right JangarooParser
configuration in ConfigClassRegistry: simply add the output
folder to classpath, not to sourcepath.
Adding the output folder to the sourcepath in ExmlXsdMojo
was already obsolete without that change: generated ActionScript
config classes never need to be scanned, because always the
EXML source is used.
Merge branch 'jangaroo-1'
[maven-release-plugin] prepare release jangaroo-tools-2.0.10
[maven-release-plugin] prepare for next development iteration
[maven-release-plugin] prepare release jangaroo-tools-1.0.3
[maven-release-plugin] prepare for next development iteration
fixes JOO-83
Package-level variable not initialized by method calls
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-83

Method calls on other compilation units were always mistaken
for static methods, suppressing the eary initialization.
Now, the compiler distinguishes calls on classes (=>static
method: do not initialize, runtime will take care!)
and calls on variables (=>non-static method: initialize!).
Ignore Jangaroo 1 release.
Merge branch 'jangaroo-1'
fixes JOO-84
Using field initializer may lead to NPE in IE11
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-84

One more indirection in calling the initializer function keeps
IE11 from mis-guessing the type and running into the error
described in the ticket.
Also, removed the old workaround for Firefox 9. The new
workaround should fix FF9, too, and even if it doesn't, FF9
is sufficiently old to no longer be supported by Jangaroo.
Merge branch 'jangaroo-1'
[maven-release-plugin] prepare release jangaroo-tools-2.0.11
[maven-release-plugin] prepare for next development iteration
Merge tag 'JOO-82' into jangaroo-3
ignore jangaroo-2 releases and obsolete bug fixes
phantomjs does not yet support Function.prototype.bind (fail!).
We could polyfill and keep this code as-is, but for only one usage this does not pay off.
A new Maven goal to generate an AMD that declares all direct Maven runtime dependencies
to other (Web)Jars as AMD dependencies. Goal: "prepare" a Maven module before starting to
load single AMDs from that Maven module.
Generate AMDs with their name as the first argument to define(), so that the resulting *.js files
can simply be concatenated ("transport format") without losing information and without using
the RequireJS optimizer that would usually be used to derive the AMD name from the file path/name.
"export" is a JS keyword, but AS does not seem to mind (used in some flashx APIs).
Fix: add "export" to reserved words and also take care of converting method names.
Normalize all AMD JS files to "transport" format, so that they can be bundled without additional RequireJS magic.