UrlEncodedQueryString CCC request

[Michael McMahon]

Here is my suggestion. It probably makes sense to keep two separate 
classes, even though UriBuilder can potentially
be used to create any possible URI. I think it is still useful to be 
able to manipulate query parameters independent
of the URI that they are to be applied to, and I think the ability to 
remove parameters and retrieve them individually
makes sense for query params (though not so much for other URI fields). 
So, to that end, I propose:

1) We adopt UriBuilder with some methods removed (can be added back in 
sub-class defined in javax.ws.rs)
     but with a build() method added that takes a UrlEncodedQueryString

2)  We remove the apply() methods from UrlEncodedQueryString because you 
build URIs now through UriBuilder.

3) Most methods in UrlEncodedQueryString need to be renamed. The word 
Parameter needs to be removed from all
    of them. So, appendParameter() becomes append(). I think 
appendParameters() should also be named append().

4) The parse() and create() methods should have the same name, and 
possibly be aligned with the creation methods
    in UriBuilder

5) I'm having second thoughts about exposing the Map outside of the 
class. I'd like to look at the reason why
    we did this again.

6) I think the separator char should be specified at object creation 
time. I can't see any great benefit to it being
    specified at the time apply() was called (though I know there may be 
some cases we still need to support, where
    different separators are used in the same query string).

Regards,
Michael