Add support for versioned stubs.

A cc_library or cc_library_shared can be configured to have stubs
variants of the lib.

cc_library_shared {
    name: "libfoo",
    srcs: ["foo.cpp"],
    stubs: {
        symbol_file: "foo.map.txt",
        versions: ["1", "2", "3"],
    },
}

then, stubs variants of libfoo for version 1, 2, and 3 are created
from foo.map.txt. Each version has the symbols from the map file where
each symbol is annotated with the version that the symbol was introduced
via the 'introduced=<ver>' syntax. The versions don't need to be in sync
with the platform versions (e.g., P for 28). The versions are local to
the library.

For another library or executable to use the versioned stubs lib, use
the new 'name#ver' syntax to specify the version:

cc_binary {
    name: "test",
    ....
    shared_libs: ["libFoo#2"],
}

Internally, a new mutator 'version' is applied to all cc.Module objects.
By default, a variant named 'impl' is created for the non-stub version.
If the versions property is set, additional variations are created per a
version with the mutable property BuildStubs set as true, which lets the
compiler and the linker to build a stubs lib from the symbol file
instead from the source files.

This feature will be used to enforce stable interfaces among APEXs. When
a lib foo in an APEX is depending on a lib bar in another APEX, then bar
should have stable interface (in C lang) and foo should be depending on
one of the stubs libs of bar. Only libraries in the same APEX as foo can
link against non-stub version of it.

Bug: 112672359
Test: m (cc_test added)

Change-Id: I2488be0b9d7b7b8d7761234dc1c9c0e3add8601c

cc/genrule.go

@@ -26,6 +26,9 @@ func init() {
 type GenruleExtraProperties struct {
 	Vendor_available   *bool
 	Recovery_available *bool
+
+	// This genrule is for recovery variant
+	InRecovery bool `blueprint:"mutated"`
 }
 
 // cc_genrule is a genrule that can depend on other cc_* objects.