refactor private->prebuilt machinery

refactor private->prebuilt machinery

Author: Brian Harring <brian.harring@intel.com>
Author: Alin Dobre <alin.m.dobre@intel.com>

New form basically extracts all relevant ABS metadata so that
the prebuilt form can use it; intention is to make the prebuilt
form basically a full drop in for the private form without any
manual intervention required.

Adds two templates; $(BUILD_PREBUILT_BUNDLE_CREATE) and
$(BUILD_PREBUILT_BUNDLE).

For creation, three vars influence it; PREBUILT_PROJECT
(grouping of modules), PREBUILT_MODULES (list of modules to scan
and convert to prebuilts), and PREBUILT_INSTALL_DIR (optional
subdirectory where prebuilt outputs should be placed); output is
written to for each PREBUILT_MODULES word, the module is written to
$(OUT_DIR)/prebuilt/$(PREBUILT_PROJECT)/$(CUSTOM_BOARD)/$(THE-MODULE).
W/in PREBUILT/$(PREBUILT_PROJECT), a usable Android.mk is generated that
uses the bundle machinery; basically is intended to handle it all.

For the bundle usage side, it's basically automatic; needs LOCAL_PATH to
know where to scan for bundles; it honors BUNDLE_TARGETS if specified-
this is the list of bundles to expose to ABS.  If unspecified, it scans
the directory and autoidentifies the bundles available.

Current limitations:
- doesn't handle modules that have multiple INSTALLED files; there is only
one the author is aware of that is valid.
- machinery on bundle side is ready for host, but creation side doesn't
yet fully identify if it's a host target or not, thus can't yet handle host.
- can handle LOCAL_COPY_HEADERS but not individual headers set
specified by BUILD_COPY_HEADERS

Change-Id: Id85660dada7d7ca218221f536515d8ac3e9729bc