Stabilize HTTP library instrumentation

Tracking issue

• #12847
• #12855
• Move AbstractKtorClientTracing (and everthing under ktor-2-common) under *.v2_0.common package (currently it has no version in the package) #12855
• #12854
• #12848
• Split unified http client/server telemetry builders into separate telemetry builders (one for client and one for server)
  • ArmeriaTelemetryBuilder #12851
  • RatpackTelemetryBuilder #12853
  • SpringWebfluxTelemetryBuilder #12852
• Ensure consistent API across all Telemetry and TelemetryBuilder classes
  • #12860
  • #12858
• Consider not using framework classes as request and response as this may limit possibilities for evolving the instrumentations without breaking changes: https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/12846#issuecomment-3503893612
• #13296
• #15101
• Emit schema url: #15144
• Normalize request/response wrapper names: #15247
• Remove deprecated classes and methods: #15324
• #15529
• #15802
• Javadocs
  • #15852
  • Ensure javadoc on all public methods
  • Ensure javadoc on all Experimental class methods #15850
• #16096
• Cleanup
  • #15825
  • #15826
  • #15827
  • #15828
  • #15829
  • #15830
  • #15942
  • #15981
  • #16009
  • #16010
  • #16011
  • #16013
  • #16090
  • Review library artifact dependencies
  • Review published maven pom files
• Final step
  • #16008
  • RC?
  • #15933

Any breaking changes should be done across two separate releases

1. Introduce the new method/class and deprecate the old method/class
2. Remove the deprecated method/class

Start by reviewing the remaining unchecked items under Cleanup and Final step, especially library artifact dependencies and published Maven POM files. Trace the completed checklist items and linked issues for context, then define the affected instrumentation modules and release constraints. Done means the remaining cleanup and final-step tasks are resolved without violating the two-release deprecation policy.