Improve performance for ByteBuddy rules with common intercept

[safris]

There are several rules in SpecialAgent that intercept the same class, such as the spring-web-* rules. These rules share the same intercept so as to allow SpecialAgent to select the correct version of a particular integration for the specific runtime. This works fine, but it costs the runtime a significant reduction in startup performance. The reason is: for ByteBuddy to apply different rules to the same intercept, it must instrument the same intercept in different layers, each on top of the pervious. This means that ByteBuddy cannot apply the intercept rules in one pass, and must do so in as many passes are there are rules for the same intercept. Currently, 68 of the 72 rules in SpecialAgent can be "globally chained" -- i.e. the rules are chained together to be loaded all in one pass. The remaining 5 rules require their own dedicated pass. Therefore, if the first 68 rules load in a time of 1, then the remaining 5 rules require a load time of 1 each (a load time of 5 total).

There are 2 ways to solve this:

1. Rewrite the spring-web-* rules in a way that is compatible for all versions of Spring Web, which may be very challenging.
2. Introduce an abstraction into the rule definition mechanism that would be able to "collate" rules intercepting the same class, and create a "compatibility-based routing mechanism" to use the correct rule definition based on the version of the instrumented library in the runtime, thus allowing ByteBuddy to instrument the runtime only once.

[malafeev]

I think we can remove spring-web-* rules because it's covered by HttpUrlConnection and thread/concurrent rules.
spring-web-* uses HttpUrlConnection to send requests.

[safris]

@malafeev, if the spring-web-* rules are providing redundant spans, then let's remove them. Removing them will also improve startup performance considerably.

[safris]

All rules involving unchained re/transformations have been fixed, except:

1. dynamic
2. grizzly-http-server
3. mule-4-http-service

In order to switch these rules from unchained to chained re/transformation, an option is to implement an abstraction into the rule definition mechanism to "collate" rules intercepting the same class, and create a "compatibility-based routing mechanism" to use the correct rule definition based on the version of the instrumented library in the runtime, thus allowing ByteBuddy to instrument the runtime only once.