OEM single-build/multi-SKU via dynamic RRO support

The purpose here is to provide support for selectively
enabling Runtime Resource Overlays (RROs) (specifically
those pertaining to a specific SKU, within a OEM's "single
build" covering multiple SKUs) at boot based on the value
of a pre-defined system property.

This mechanism is designed to be compatible with other,
recent changes to Runtime Resource Overlays - specifically:

- has no effect on 'isStatic'. Resource overlays must be
  attributed as static in order to qualify for loading into
  the system_server. The 'requiredSystemPropertyName/
  requiredSystemPropertyValue' mechanism operates
  independent of this and can be used on both static and
  non static overlays. The effect of specifying a conditional
  property on any overlay is that it will ONLY be enabled
  in the event that the system reflects both the property
  and the specified value (Note that in the ABSENCE of a
  conditional property, overlays are assumed to be enabled).

- has no effect on OverlayManagerService (OMS) API. The
  OMS provides the system with an interface through which
  overlays can be enabled/disabled and even rearranged at
  runtime. This provides the basis of support for various
  user-level features (e.g. dynamic theme selection).
  The 'requiredSystemPropertyName/requiredSystemPropertyValue'
  mechanism operates independent of this -
  with enablement being completely coupled to the available
  system properties on the device and NOT subject to change
  at runtime.

Note: as part of this change, original overlay tests have been
updated (fixed) and expanded to include tests to cover the
conditional property implementation.

Issue: http://b/35100249
Test: frameworks/base/core/tests/overlaytests/testrunner.py

Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
(cherry picked from commit d5566c6c)