Revamped asset layout in preparation for Android asset change.
No sources in main jar; use source jar from Maven.
New asset strategy: assets are stored in directory named assets.

This has one big benefit and one small one: the big benefit is that this allows
us to use AssetManager to load things on Android which allows us to avoid
making cached copies of sounds and fonts. The smaller benefit is that projects
all put their assets in a standard place and they can all stop having to call
setAssetPrefix (except on HTML5, where GWT fiddly business requires it).

In general this will mean a project has assets thusly:

core/src/main/resources/assets/...

but varying degrees of Maven jockeying will allow you to put them wherever you
want as long as they end up under assets/... in your jar file.
Updated archetype to use new assets layout.
More asset related revampery.

Android handles the inclusion assets into the APK specially. Specifically, it
does not compress a variety of (already compressed) files when including them
in the APK. This is necessary so that it can later mmap() the data for those
files for use by, for example, MediaPlayer.

Because our assets are in the core project and then included into the android
project (and thence the APK) as a plain old dependency, aapt doesn't know they
should be treated as assets. So we pull our assets out into a separate
sub-project (like we do on iOS) and use a symlink in the standard Android
assets location (${projdir}/assets) to cause them to be picked up and treated
like proper assets.

The symlink will of course cause problems for Windows users, because Windows
(or Git on Windows, or something) is still stuck in the mid-20th century, but
we'll just have to find a way across that bridge, because having our assets
handled properly (instead of having to copy them to a temporary file system
before reading) is too juicy to pass up.
Upgrade to latest Android Maven plugin.
Log sound load errors, and use offset/length for asset FD.
Update the archetype with separate assets submodule.

It turns out there's a Maven mojo that creates symlinks, so we might be able to
use the symlink approach without incredible pain. I'm sure Eclipse will choke
and gargle on the plugin and things won't work out of the box there, but when
have things ever worked out of the box on Eclipse?
Generate the assets symlink rather than commit it to git.

Symlinks committed to git don't work on Windows (last I checked), so this
should be more likely to work for more people.
Generate the symlink used to share test code.

This used to be committed to Git, but that has always caused problems for
Windows users. Maybe now it will be possible to run the tests on Windows...