Naming inconsistencies for HTTP filters

[NiteshKant]

HTTP APIs follow the convention:

• For aggregated APIs (non-streaming): No qualification is present in the names. eg: HttpRequest, HttpResponse.
• For async streaming APIs: We prefix with Streaming. eg: StreamingHttpRequest, StreamingHttpResponse
• For blocking streaming APIs: We prefix with BlockingStreaming. eg: BlockingStreamingHttpRequest, BlockingStreamingHttpResponse

However, we only provide ways to add async streaming filters, so we drop the qualification in the name. eg: TracingHttpServiceFilter extends StreamingHttpService but it does not have a name qualification according to the above convention. The rational is to reduce naming verbosity at the cost of not following the conventions.

Not following conventions can cause confusion for users and we should revisit to see if we can reduce this confusion.

[NiteshKant]

Some relevant discussion here: https://github.com/servicetalk/servicetalk/pull/112#discussion_r223803835