DWR

I've checked in an initial stab at this issue with updates that decouple DWR's core so it doesn't require remoted objects to be made of reflectable concrete Java classes accessible through DWR's classloader, but instead get a logical representation that may be customized by integration code.

This has been done by adding these classes:

Module and ModuleManager interfaces,
that provide a more generic integration point in DWR's conversion pipeline, compared to Creators that are hard-coded to reflection.

MethodDeclaration class,
that is the representation of a logical method, not necessarily backed by reflection.

and these new injection points in the DWR conversion pipeline (in defaults.properties):

moduleManager,
a MasterModuleManager that delegates to customModuleManager and fallbackModuleManager in that order

customModuleManager,
empty by default and may be configured by applications to activate custom integrations

fallbackModuleManager,
a CreatorModuleManager that interfaces against the standard Creator infrastructure (including some required internal DWR services)

Changes to existing code:

There are small changes to many files, but the major part of the code changes are in the following modified interfaces:
AccessControl
and core classes:
Call
DefaultRemoter

The new interfaces may be considered experimental, and this work should be continued in follow-up activities after 3.0.

Checked in some more improvements that allows registering conversion of classes from other classloaders than the one that loaded DWR. This is done through ConverterManager.addConverter(Class, Converter) where the Class may come from another classloader. These Classes are then referred to by Modules' MethodDeclarations.