Allow sdk_version: "system_server_current" modules to access module-lib APIs

Previously, a java module with sdk_version: "system_server_current",
would only be able to access the system server or public API of a
java_sdk_library. This change allows it to access the system server,
module lib, system and public APIs in that order.

The apiScope structs define the characteristics of each of the
different API scopes used as required by the java_sdk_library. They are
organized into a hierarchy which is used for two different purposes.

The first purpose is to define an extension hierachy. If scope X
extends Y then X provides a superset of all API elements (classes,
fields, methods, etc) provided by Y. That is reflected in the fact that
the .txt file for X would be a delta on the .txt file for Y. So, system
extends public and so system_current.txt only contains additional API
elements to add to current.txt.

The second purpose is when a java_sdk_library/import is asked to
provide a specific API scope. e.g. a library that has:
    sdk_version: "module_current"
will ask each of the SDK libraries it depends upon for a module-lib
API. However, not all of them will provide an API for that scope. In
that case it will find the closest suitable API scope.

Previously, it did that by traversing up the API extension until it
found an API scope that it did provide and return that. As
system_server_current extended the public API that meant that a library
which has:
    sdk_version: "system_server_current"
would provide a system server API if available, and if not fall
straight back to public. That meant that the library could not access
system or module-lib APIs even though it is running in the system
server which should be able to access all APIs.

One way to fix this would have been to just have system server API
scope extend module-lib but that would have had a number of nasty
side effects:
* It would have created a significant overhead as every module that
  provides a system server API would also have to provide a module-lib
  and system API, along with their corresponding .txt files.
* Each existing java_sdk_library that provided a system server API
  would need those .txt files created.
* Generating sdk snapshots for older releases would have been more
  complicated.
* It would have confused developers.

All of that would be unnecessary because the system server API scope is
intended to be provided by libraries that are used solely by the system
server so there is no point in them providing anything other than a
system server API.

So, instead a separate access hierarchy was added which is the same as
the extension hierarchy for all existing scopes except for the
system server scope, which instead of just being able to access the
public API will be able to access the module-lib scope, which can in
turn access system and it can in turn access public.

That achieves what we want which is a library that is loaded into the
system server to be able to access all API scopes.

Bug: 204176972
Test: m nothing
Change-Id: I854df63fcaeba32afbc1eb0d1a501238022673d0