Use source_module_name to determine the contents of prebuilt apexes

There are a couple of instances in apex/ and java/ that rely on the naming
convention that the jars exported by prebuilt apexes follow the name of
the java_sdk_library_import, minus the prebuilt_ prefix. With muliple
module sdk prebuilts in trunk stable, this naming convention might not
be valid. Use `source_module_name` instead.

```
prebuilt_sscp_fragment {name: "", contents: ["service-foo.v2"]}
java_import {name: "service-foo.v2", source_module_name: "service-foo"},
```

We should use service-foo and not service-foo.v2 because
1. The prebuilt apex contains service-foo.dex
2. PRODUCT_*JARS will contain service-foo and not service-foo.v2

For clarity, this CL does not drop the current mechanism where prebuilt bcp
fragments create a dependency edge to prebuilt java or java_sdk_library
imports. There is still some discussion around whether we can remove
that completely (b/320711431). If we were to do that, then the
Android.bp files will become

```
prebuilt_sscp_fragment {name: "", contents: ["service-foo"]}
```

Bug: 322175508

Test: Added a unit test

Test: In internal, lunch cf_x86_64_only_phone-next-userdebug && m
nothing # .ninja files identical

Test: In internal, created a parallel set of v2 prebuilts of
java_sdk_library_import and prebuilt_bcp_fragments for adservices && m
nothing # build passes

Change-Id: Ia899d75e826fa1a559368d706eaa65835f748d40

java/classpath_fragment.go

@@ -103,8 +103,8 @@ type classpathJar struct {
 func gatherPossibleApexModuleNamesAndStems(ctx android.ModuleContext, contents []string, tag blueprint.DependencyTag) []string {
 	set := map[string]struct{}{}
 	for _, name := range contents {
-		dep := ctx.GetDirectDepWithTag(name, tag)
-		set[name] = struct{}{}
+		dep, _ := ctx.GetDirectDepWithTag(name, tag).(android.Module)
+		set[ModuleStemForDeapexing(dep)] = struct{}{}
 		if m, ok := dep.(ModuleWithStem); ok {
 			set[m.Stem()] = struct{}{}
 		} else {