Modularize project so Android instrumentations can used by SDKs that provide their own OpenTelemetry instance

Background

Conceptually, the core module provides serves three purposes:

1. Initializes an instance of OpenTelemetry with reasonable defaults
2. Defines an API for Android instrumentations and orchestrates the starting of the configured instrumentations
3. Provides a set of opinionated abstractions over the Android platform that instrumentations can depend on (i.e. Services)

As an app developer, using this project is straightforward: include the android-agent module, configure and start the SDK, profit.

However, as @surbhiia points out in #669 , vendors that have their own version of android-agent that are used with their own custom instrumentation can't use the instrumentations provided by this directly.

Part of that is intentional:- the platform abstraction services are a dependency, so they must be provided by the project to the instrumentations for them to work. But is there a good reason why the OpenTelemetry instance has to be created in core? To put in another way, does the use case outlined in #669 seems reasonable? I think the answer is yes.

This issue is about doing all the work to enable the use of instrumentations defined in this project independent from the initialization of the OTel SDK.

Goals

• Restructure core so that purpose 1 listed about (i.e. initialize OpenTelemetry instance) is outside of its direct purview
• Refactor the initialization of the services so they are done lazily, in case they are not all needed for the specific set of instrumentation that are in use.

Non-Goals

• Make the interfaces of the platform abstractions public, i.e. they should remain internal and not be part of the supported public API. In other words, those interfaces and implementations should not be explicitly depended on by app and they can change form version to version with no warning.
• Make the interface for the Android instrumentation public, i.e. apps can't create their own instances of instrumentation that are then managed by core. In other words, AndroidInstrumentation will NOT be a publicly supported API.

Review the core and android-agent module boundaries and the use case described in #669; identify where OpenTelemetry initialization and platform services are coupled. Done means instrumentations can use a caller-provided OpenTelemetry instance and services initialize lazily without making the excluded interfaces public.