* using light-weight AMD implementation "almond" for
  linked and minified version
* added build descriptors for linked and minified builds
* merged all polyfills into one file which is always linked
  -- no more shim.js to reduce complexity
* translating main code into AS3 (HelloWorld.as) and making
  it a "real" faked generated code file (HelloWorld.js),
  boot-strapped by new file application.js
* moved trace*.js to classes, as although it is built-in, it is
  top-level AS3 API, not runtime support
* merged all runtime helper functions into one module "runtime.js"
* all other modules use this to define a class or an interface and
  to use bind, as, is, and cast.
Isn't AS3 a better name for the "runtime"?
...and the linked + minified versions of the previous change
got rid of staticInitializers. Like non-static ones, they are now
inlined into the initialization code.
Reworked class initialization.
After some "real" AS3 experiments, I found out that a class is always
initialized when accessed in any way, even when used in an "is" expression.
Thus, it seems more straight-forward to access a class through a wrapper
that takes care of "building" the class on first access; something like a
"future" class.
Thus, every AMD file defining a class now no longer returns the class itself
(constructor function), but an object with a single property "_". When reading
this property for the first time, the actual class is built and returned, replacing
the property "_" by a simple reference to the class, speeding up subsequent
accesses.
To make this also work in IE < 9, where not get property functions are available,
alternatively, a function get$_() is defined.
While already at this problem, I also changed the runtime to define such
get$foo / set$foo functions for all other properties and modified the AS3
example to actually do a little bit computation in the getter setter of "msg".
Reading / assigning a property foo defined by get / set should now always be
rewritten to calling the corresponding get$foo / set$foo function.
As soon as we drop IE < 9 support, this feature of the cross-compilation can
simply be disabled and the runtime can be simplified.
The advantage of the new approach is that untyped usage of a property defined
by get / set will at least work in modern browsers, and the runtime overhead is
minimal to non-existent. Only readability of the generated code suffers a bit.
comments on get/set emulation not being necessary in ES5 browsers
optimized AS3.bind():
Using hasOwnProperty() allows using the same name for
the bound method as for the unbound one and should even
be faster, as it avoids lookup along the prototype chain.
using "exports" instead of returning the AMD module value.
This makes circular dependencies between compilation units possible.
for minification, configure optimizer to also exclude license comments (the one of almond.js)
then re-generate linked and minified versions after changes of previous commit
enabled sourceURL for linked build and source maps for minified build.
At least in Chrome, this allows convenient debugging even in linked mode
(the one big file is "simulated" to be the many small ones) and in minified
mode (the minified file is at least mapped to lines in the one big, readable
file, where you can for example set breakpoints).
Firefox is supposed to support sourceURL, but for some reason, it does not
work with this example. Have to investigate.
The sourceMap should really map from the minified file directly to the
multiple ActionScript source files, but this is not yet supported by RequireJS'
optimizer.

Also moved almond.js into the "runtime" subdirectory because it is only
used for linking.
Re-generated all JavaScript files with Jangaroo 3 and manually
simplified according to the proposed code layout for Apache Flex.
Added the RequireJS plugin "native", which takes care of integrating
with "native" JavaScript. This adds a fourth option for linking the
application: use RequireJS (not almond.js) to load minified
application, and load es5-polyfills only if needed (IE8).