Allow for media to be dynamically downloaded

The way Ember currently works is that it's distributed with a full set of media, and whenever it's run it connects to the WFUT service on amber.worldforge.org to see if there's any new media, and if so downloads it.
This needs to be changed so that it can download media on demand instead, when required. This requires two new features:
1) Ability to specify server-instance specific media.
2) Ability to let the client find and download needed media in a background thread, and show it in the world when needed.

This blueprint only deals with the second part.

The main reason for the static way that media is handled is that versions of Ogre older than 1.6 didn't have a good way to deal with duplicate resource names. When a duplicate resource was found an exception deep inside of Ogre was thrown, resulting in a broken resource model.
However, with 1.6 we now have the option to allow for correct handling of duplicate resources and can thus implement full dynamic download.

The main entry point for how media is defined and loaded is the model mapping framework in collaboration with the model system. The model mappings tell Ember what models should be used for what entities, and the models themselves then specifies the meshes, materials, textures, particles etc. that should be used. In addition there's the terrain layer definitions, which define how the terrain should be represented, what materials and textures to use for the different layers and so on.

An implementation of this blueprint would therefore require an initial explorative phase where it would be decided how the dynamic features should be implemented, and where it should hook in. We should provide support for both arbitrary urls ("http://www.foo.com/textures/bar.png") and predefined media locations ("foo:textures/bar.png" given that we've previously defined "foo=http://www.foo.com"). The latter could be used in worlds where the creator want better control of from where media is references. In such case it should also be possible to disable the arbitrary urls.
However, I do think that it's best to not prohibit the use of arbitrary urls since we do want to encourage an open system and don't want to put up unnecessary hinders.
No matter how the resource locations are specified we still need to look into where in the system we should allow for remote resources, and how discovery should be handled. Should we still send all model mapping and model information at startup, and then letting the resource system do lazy initialization on the actual meshes and textures? Should we allow for discovery of new models, and how? How do we handle live updates of media?

One thing to consider is that we want to avoid using a specific media server. The existing infrastructure on the internet for media discovery and download is already sufficient for our needs and we don't need to put any resources into creating a WF specific system for this.

Once the discovery phase is complete we need to implement the dynamic downloading. This involves making sure that all resource handling takes this into account, and that nothing breaks when there's missing media or media which haven't been loaded yet. Some initial work has already been done with how Ember now supports background thread downloading. A much wider approach needs to be taken with this feature however.
Ember uses the Ogre resource system for most resource loading, and this allows for extensions and callbacks to be hooked in, to make this easier to implement.

This blueprint does not involve caching of remote data locally, this is left for another blueprint.
It also doesn't handle how to present non-downloaded content (transparent etc.).

This blueprint can be considered done when it's possible to define the locations of all media resources belonging to a model using remote urls, and then having Ember automatically download it all.