Reworked some TCK test cases

[Martin Scott Nicklous <Sc...@de.ibm.com>]

I completed rework of the tests derived from the API documentation to place
the test case code on the proper method and generate test case names that
contain the module name. Also changed the module build so that all portlets
from each module are on a single portal page rather than having only a
single portlet on the page. This affects the following modules:

V2FilterTests
V2WrapperTests
V2RequestTests
V2ResponseTests
V2URLTests
V2ExceptionTests
V2AnnotationTests
V2PortletTests
V2EnvironmentTests

I also implemented some of the test cases:

* Implemented all of the wrapper tests
* Implemented tests that static fields have the specified value
* Implemented all tests where a null value will cause an
IllegalArgumentException

The wrapper tests verify that the wrapper class calls the correct wrapped
method with the same parameters that were passed to the wrapper class
method. The return value is also tested. It turns out that one of the tests
fails. The ResourceRequestWrapper#getPrivateRenderParameterMap method is
supposed to  call the wrapped ResourceRequest#getPrivateRenderParameterMap,
but instead it calls the getPrivateParameterMap method. This is a bug in
the JSR286 API code itself. I'll open an issue for this shortly.

There are still quite a few test cases that remain to be implemented, but
in terms of the test case definitions, I think we're pretty much complete.
There are a few "holes", though:

* There are no tests that events can be delivered to subscribing portlets
in other web modules. Maybe this test can be added to TestModule 3.
* There are no tests that submitted form parameters are correctly
integrated into the action request parameters. Maybe this test can be added
to TestModule 3.
* The test cases defined so far concentrate on a specific method. There are
no tests that cover end-to-end scenarios. I think it would be good if at
least some such tests could be added, even though it might require adding
another selenium test driver if it turns out that such cases can't be made
to fit the current simple test driver sequence. It would be good if someone
could have a look at that .. I won't have time to look into it for quite a
while, probably. When I refer to "scenario" tests, I am thinking of tests
like the following:

   "The user submits a form causing a public render parameter to be set. In
a separate portlet, an image based on the PRP is generated and downloaded
through serveResource"
   "Several portlets in a portlet application use a common portlet filter
to set headers"
   "... other ideas ..."

Going forward, I won't have much time to implement more tests. However, the
modules V2RequestTests, V2ResponseTests, and V2URLTests contain a high
number of repetitive tests (i.e. same test for each request, response, or
URL type)  that lend themselves to my process. As time permits. I'll try to
implement the tests in these modules.

regards,
Scott