Add flatbuffer support for COM configuration using flatbuffers

[OliverHeilwagen]

resolves #110

This initial version was focused on working ipc bridge test using flatbuffers, quality aspects are not yet covered.
It is recommended to break down the issue into smaller tasks and setup a merge strategy, PR is therefore draft only.

Pending decisions:

• Runtime switch between JSON and Flatbuffers, currently based upon file extention .json, .bin
• Common approach for:
  • Buffer version identification on target (file_identifier + common version info)
  • Schema evolution handling (example)

Changes (rough outline)

• Added generate_com_config rule (bazel/tools)
  • Convert existing json to flatbuffer friendly version (key snake_case, enum friendly values)
  • Creates buffer from converted json
• Abstracted config_parser with config_loader
  • Switch between JSON, FlatBuffer depending on file extension (see above)
• Added FlatBufferConfigLoader
  • Initial version tested via:
    • unit_test_runtime_single_exec
    • ipc bridge example

Open points:

• Quality Artifacts not touched (Requirements, Architecture, ...)
• Tracing configuration is still json only
• File loading (open, mmap) should be moved to separate library (baselibs? I only saw fstream based abstraction)
• Flatbuffer schema check can't check for value ranges
  • generate schema from *.fbs via flatc using --jsonschema
  • extend schema and add verification to generate_com_config rule
• Add option to generate_com_config to update tracing config file from json to bin
• Add version info to COM FlatBuffer format, to allow for version identification on target.

[LittleHuba]

Thank you for sharing this initial version of the flatbuffer support.
We will give this an initial review and get back to you with feedback as soon as we can.

[LittleHuba]

See also general discussion here: #110

[OliverHeilwagen]

Change back to info before merging PR. Warning is currently only used to see effect in ipc bridge test.
Same applies to json log.

[OliverHeilwagen]

@LittleHuba @castler @hoe-jo:
I guess we should first decide on the scope of this PR.
We could for example leave out this change to not yet allow for actual usage of flatbuffers by a user of COM and only introduce a initial set of changes e.g.:

• mw/com/impl/configuration
  • ara_com_config.fbs
  • flatbuffer_config_loader.h/cpp
  • including the respective quality artifacts architecture, ..., tests
• bazel/tools

Please coordinate with @Thomas-Mikhael he will takeover the PR.