Extract modules from core

[surbhiia]

As a first step towards #669 , I've extracted following 3 modules from core:

:common

• Holds classes which are required in :core, :services and some instrumentations too like RumConstants.
• Not published so keeping it internal. Added as implementation dependency everywhere.
• Had to extract networkattrs->data and CurrentNetworkAttributesExtarctor here as it is utilized by both :services in CurrentNetworkProvider and :core in NetworkAttributesSpanAppender.
• Extracted RuntimeDetailsExtractor used by crash instrumentation here.

:services

• The services folder in core is extracted as a module
• Moved SystemTime class here as well as it is a good contender for a shared utility. It is currently only used by the PeriodicWorkService. Alternatively, We can move it to :common module (Update - moved to :common now)
• Not published so keeping it internal. Also used internal keyword in package name. Added as implementation dependency everywhere.

:instrumentation:android-instrumentation

• AndroidInstrumentation AutoService interface and related classes
• This is published as currently we're allowing users to bring in their own custom instrumentations that implement this interface and add via the addInstrumentation() API we have exposed. Added as api dependency everywhere right now.

Other callouts:

• Preferences.java in service module depended on the generated BuildConfig.java for LIBRARY_PACKAGE_NAME for getting the shared preference object. It does not make sense to generate BuildConfig.java in any other module other than :core as it is project specific. So, I've replaced the dependence by direct replacement with "io.opentelemetry.android" string. Also, it did not make sense to add this string to RumConstants and use from there.
• test/resources/META-INF/services and TestAndroidInstrumentation is replicated right now in :core and :instrumentation:android-instrumentation modules as it is just providing an AndroidInstrumentation AutoService on the classpath for tests in both modules as those tests are specific to the individual modules (AgentInitTest, OpentelemetryRumBuilderTest, AndroidInstrumentationLoaderImplTest). (While writing this, it comes to my mind that we can perhaps move TestAndroidInstrumentation as a shared test class in test-common module.)

This is just a first step, we've a long way to go in determining the future possibilities of how we can support instrumentations to be used independently of this SDKs core (initializing and configuring) module. Those discussions are covered in following issues - #658, #669 , #702.

Screenshots of the new modules structure from android studio project explorer:

[LikeTheSalad]

Thanks! I think it's a good start. I do believe we should move SystemTime to common though, as you mentioned:

Moved SystemTime class here as well as it is a good contender for a shared utility. It is currently only used by the PeriodicWorkService. Alternatively, We can move it to :common module

It's pretty common having to use the current time and it's tricky to test those use cases without something like SystemTime. Here's an example of a usage outside of the services scope where having it in common should help.

Other than that I think we can move forward with these changes, though I'll leave this PR open until next week to give a chance for people in the US to have a look too, as I've noticed that this week has been pretty quiet in OTel in general due to the holidays.

[breedx-splk]

This feels like progress. Thanks for contributing this!