Rename InApexes -> InApexVariants

.. in preparation for the upcoming change. This change doesn't alter any
behavior.

InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.

However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.

Bug: 180325915
Test: m nothing

Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436

java/hiddenapi_singleton.go

@@ -167,11 +167,11 @@ func isModuleInConfiguredList(ctx android.BaseModuleContext, module android.Modu
 	// Now match the apex part of the boot image configuration.
 	requiredApex := configuredBootJars.Apex(index)
 	if requiredApex == "platform" || requiredApex == "system_ext" {
-		if len(apexInfo.InApexes) != 0 {
+		if len(apexInfo.InApexVariants) != 0 {
 			// A platform variant is required but this is for an apex so ignore it.
 			return false
 		}
-	} else if !apexInfo.InApexByBaseName(requiredApex) {
+	} else if !apexInfo.InApexVariantByBaseName(requiredApex) {
 		// An apex variant for a specific apex is required but this is the wrong apex.
 		return false
 	}