Remove `classes_excluded_from_instrumentation_default`?

[felixbarny]

I think classes_excluded_from_instrumentation_default does more harm than good. It doesn’t seem to reduce the startup overhead and it can lead to surprises when trying to instrument something that has been globally excluded.

Let's remove it if there are no objections.

See #1920 (comment) and #1920 (comment) for more details.

Relates to #1920

[eyalkoren]

IIRC, these exclusions are not entirely about startup overhead (matching), some are related to runtime overhead (e.g. instrumenting and wrapping in non-required executors through the concurrency plugin) and even possibly functionality-related.
Sorry for not being able to provide concrete examples...

I don't have a great alternative to propose either though, other than extending the default exclusion list as part of the instrumentation PR to allow instrumentation of the required package/class.
In order to address the problem of the time spent for realizing this is the problem, we can add a check to the advice validation to match against this list and issue a clear warning when an instrumentation tries to instrument something that is matched against it. This won't work if the instrumentation only relies on class hierarchy and not on naming, but we don't want such matchers anyway...

This is my two cents, but since this is just general fear of regression and not concrete information about expected issues, don't consider this as an objection but only as an additional consideration.