Added processing in DOMRenderKit to scan for new MandatoryResourceComponent annotation on Renderer objects. If they're found, add the component class name from the annotation to a list, which BridgeSetup retrieves on each lifecycle.

Original strategy was to instantiate a dummy instance of each component, and temporarily add it into the component tree, hoping that would trigger its @ResourceDependency / @ResourceDependencies processing, so the internal JSF mechanisms would handle the resource adding. This didn't work. I didn't really have time to investigate why. So, I fell back to Plan B, which was to process the @ResourceDependency / @ResourceDependencies annotations right in BridgeSetup. Found out that our code had to handle the case where the target is null, and needs to be defaulted to "head". Also found a way to get JSF to automatically handle javascript and CSS files, without us having to parse that out ourselves. Finally, added redundancy culling, so that all the redundant resources, which multiple components require, will only be added once.

Subversion 22825

One lingering question is whether all the Class.forName() code should be done once in the DOMRenderKit, instead of per lifecycle in BridgeSetup. Just not sure if we want to classload the component during the RenderKit processing. If it's alright, it would be more efficient. Perhaps if that logic were moved into DOMRenderKit, then it would be easy to switch when it happened, on list creation, or list retrieval.

Committed the ace component Renderer classes, with their @MandatoryResourceComponent annotations.
Subversion 22827

There should be no problem with classloading the components in the DOMRenderKit – this is a small number of classes compared to what is otherwise required to start the application.