Add (build+run)time mechanisms to enhance hw detection and platform options

NOTE: Description rewritten on July 6th 2018

4 steps envisioned:

• at build time, add information for static build information, like machine, agl features, layers commit ids (manifest) etc. The SDK should also expose the same information, so that they can be reused when packaging apps to add automatic platform dependencies (ex: an app would require AGL version >= 5.0.3 because SDK has version 5.0.3)
• at first boot, add information related to "deep" hardware detection, like detecting hardware features that can't be specified as machne-specific. Scriptlets mode envisioned here = add a way to specify a script fragment at build time that would land in the right folder to be launched at first boot. This is very close to the first boot mechanism to install widgets, propbably occuring earlier in the boot workflow.
• at each boot, add information related to "quick" hardware inspection, like: HDMI connectors enabled, USB devices piugged in ... anything that could change from one boot to another (= we're close to hotplug and udev rules). Again, scriptlet mode envisioned here, to let every package ship a script fragment that will try to detect things.
• at any time (build, firstboot, later...), a custom vehicle-specific file could be added for custom options not so related to hardware but more to integrator choices

For each step, try to have a commonality:

• same utility/method  to generate/modify files (kinda very simplistic registry tool), used as native tool during build or on the target from firstboot+boot detection scripts
• 1 file per step. Proposal:
  • /etc/platform-build-info: static info from build
  • /etc/platform-hw-info: firstboot detection, mostly dedicated to static HW config
  • /etc/platform-runtime-info: every-boot detection
  • /etc/platform-custom-info: customization, left to integrators
• dual format mode for each step
  • /etc/platform-xxxxx-info with "shell format" (=the same as etc/os-release AKA LSB format):  VAR="value" - useful for shell scripts and systemd env sourcing
  • /etc/platform-xxxxx-info.json with JSON format, mostly useful from bindings which are used to read and parse json easily, but also to put some extra "complex" data structures less accessible in shell format. Typical examples: complex objects like full build manifests (=yocto layers git + commit IDs + branches)

Outcome:

• make support easier (customer:"I have an issue on my AGL image bla bla bla"; operator:"please push me your /etc/platform-build-info")
• provide a basic framework for runtime detection (usable in 4A for audio HAL adjustments, gfx environment, sensors network detection; network detection ...)

Hope to see many "platform-build-info" attached to Jira issues!

Update 2018-11-20:

• let's put all files in /etc/platform-info (instead of /etc)
• a binding is being created to abstract the information (see apps/agl-service-platform-info)