Support multiple values in Spring @RequestMapping annotations

Description

Currently, if a Spring @RequestMapping/@GetMapping/etc annotations have multiple entries in their value attribute, the agent will only use the first value element to name the transaction. For example:

@RequestMapping(value = {
        "threadData/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}",
        "threadData/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}/{optionalBlobId}",
        "threadData/accounts/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}",
        "threadData/accounts/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}/{optionalBlobId}"},
        method = RequestMethod.GET, produces = "application/json")

Regardless of the URL pattern used to invoke this controller method, the transaction name will always be:
threadData/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}

The agent should implement logic to match the underlying, concrete URL to the correct mapping value if more than one value pattern is present. In the above example, the URL threadData/accounts/1234/abcdef/0987654/qwerty/asdfg/zxcvbn would map to threadData/accounts/{accountId}/{clusterAgentId}/{fingerprint}/{buildUuid}/{occurrenceUuid}/{optionalBlobId} (match on two constant URL parts and 6 variable parts).

Internal Slack thread.

Acceptance Criteria

Spring WebMVC based transactions are named properly when multiple URL patterns are present in the value attribute of the mapping annotation.

Design Consideration/Limitations

Only perform the extended check if the value attribute array has a length > 1.
Cache compiled regexs that correspond to entries in the value attribute? (Keyed by method signature?)
Gate the extend check behind config in case performance issues pop up.

No files or tests are named. Start by locating the Spring WebMVC transaction-naming logic and its existing tests, then trace how @RequestMapping and related annotations supply multiple value patterns. Done means a concrete URL selects the appropriate pattern for the transaction name, while the single-value behavior remains unchanged.