Refactor to common HTTP transaction naming strategy

## Problem description

Issue discovered while trying to add support for a new high-level HTTP framework (Spring Webflux).

We have a few different strategies when naming HTTP transactions:

- Servlet (low-level, uses what is available at HTTP level), two configuration options:
- `use_path_as_transaction_name` : might create high-cardinality for transaction names
- `url_groups`: allows to restrict issues with `use_path_as_transaction_name`
- needs to deal with JSPs

- JAX-RS (high-level framework)
- by default naming is defined with `ClassName#methodName` of the matched resource method
- `use_jaxrs_path_as_transaction_name` allows to reuse path template `GET /item/{id}` instead

- Spring MVC (high-level framework)
- by default naming is defined with `ClassName#methodName` of the matched controller method
- no option to use any request pattern (which is likely to be made available by Spring MVC as a request attribute).

- Spring Webflux (high-level framework)
- Similar to Spring-MVC, not yet merged (see #1305).

Common
- name should be set to `GET unknown route` when the transaction name is not known.

## Proposal

- provide a common configuration option similar to `use_jaxrs_path_as_transaction_name` but not framework-specific
- avoid duplication for every framework
- provide fallback to what is available to prevent unnamed transactions
- optional: allow to re-use low-level naming strategies for non-Servlet frameworks (Jetty, Netty HTTP, ...).
- optional: avoid common causes of high-cardinality by ignoring `use_path_as_transaction_name` for `404` (actual value is still available in `request.url.full` if required for investigation.