Define NNAPI Extensions types

Machine Learning is a fast moving domain: new operations and data types
are introduced at a staggering speed. The Android API, on the other
hand, evolves on a yearly cycle. Many application developers, OEMs, and
SoC vendors would like to be able to define new operations at a faster
cycle.

In OC-MR1, NNAPI provided a simple mechanism to mitigate this problem:
two OEM data types and an OEM operation. The downside of this mechanism is that
it is simplistic: There’s no guarantee of consistency between vendors.

Examples of features that are required by the first parties' use cases
that we would like to be able to define outside of the normal Android
release cycle:
- New data types:
  - Sparse tensor (used by some speech generation models).
  - 16 bit int tensor (needed by OCR).
  - 16 bit float tensor.
- New operations:
  - 16 bit quantized LSTM (needed by OCR).
  - Basic primitives like sqrt and floor.
  - Logical operations.
  - Complex neural network layers.
  - Control flow.
- Enhancement to existing operations:
  - Concatenate supporting different scales/zeroPoints for arguments.
  - High-dimensional tensors.
  - Ordering of dimensions.

We are going to provide support for two types of extensions:
- NNAPI Platform extension. This is functionality that will become part of
  future releases of NNAPI. These extensions provide generic,
  non-vendor-specific functionality. Only the Android team can define new
  platform extensions. These extensions will be defined in the master
  branch of AOSP. Each extension comes with:
  - Documentation defining the extension,
  - A header file for the new constants,
  - A parameter validation library to be used by drivers, and
  - Validation tests akin to the CTS and VTS tests.
- Vendor extension. A vendor-specific extension is an alternative to OEM
  operation and data types. Its usage will be limited only to first party apps
  preinstalled on the /vendor or /odm partition.
  Each vendor will be identified by a specific value to
  prevent collisions between multiple IPs found on the same SoC. This
  effectively creates a vendor-specific namespace. These identifiers are
  assigned by Google.

This change only defines the new interface. The implementation follows
in changes Ie4e2530e4c81fabe4eb59b7a6ba4a3b4bb483bd1,
I02aa12f4a8444012ddf3b20c2bfbba6a21ce9ce9, and
Icf59ed04e602aa7a730eb1eb45e5f6b1204fafb3.

Bug: 118605927
Test: mma
Change-Id: Ia9b99015eec7a48bbf969cbe503862271f09adca
Merged-In: Ia9b99015eec7a48bbf969cbe503862271f09adca
(cherry picked from commit 92120185)