REDHAWK 2.2.1 Support

[btgoodwin]

Several internal and customer issues are closed in this merge. Below are some of the highlights.

• REDHAWK 2.2.1
  • OmniORB, OmniORBpy, and OmniEvents version bump (99c761f)
  • Massive re-organization to more easily support multiple versions of REDHAWK at the head of the layer in addition to using the independent repos to help with build speed (vs. the top-level submodule-filled redhawk one) (9b58efc)
  • Moved all preferred versions to a global location (old location had no impact on builds), again for easier support of multiple RH versions and deps in the future. (17f2fb1)
  • Moved REDHAWK_PROCESSOR to global conf (25909a9)
  • Addressed bug that made the REDHAWK_PROCESSOR dynamic patching be non-repeatable (951ff5c)
  • Introduced tooling to patch ComponentHost, SoftPkgs and Components implementations such that the produced binary (or library) will not collide with the x86 version. In the past, we would "clobber" the x86 with our built REDHAWK_PROCESSOR implementation. Now we add a new implementation and install that. The same tool (scripts/spd_utility) can then install that new implementation onto an x86 domain to coexist with other implementations, making a multi-implementation domain easier to maintain (951ff5c). This change also required adding -native packages for redhawk and other recipes.
  • Changed default REDHAWK_PROCESSOR value to follow HOST_ARCH which seems to be a bit more consistent (939434c). Users can now build qemuarm64 with the redhawk-test-image and get a running domain with GPP and services with all components installed for testing, for example.
• Moved giflib to be inline with meta-oe's location (recipes-devtools) (ad1ba05)

GitHub issues and PRs:

• Closes PR #25 by duplication at 2db7ec8 (and 9ad4539). Thank you all for your pointing this out!
• Closes #20 through the redhawk-entity.bbclass's use of the scripts/spd_utility to patch recipes. (951ff5c)

[btgoodwin]

The big re-org helped make the "core" of the recipes be reusable like other vendors have. The side-effect is that the components directory, for example, looks unwieldy with how full it is. This may become worse if we start adding additional versions to it, but perhaps we cross that bridge when we come to it.

[btgoodwin]

For those reviewers who have the time, feel free to shake this down by building a qemuarm64 with redhawk-test-image. When you runqemu, it should roll straight through the bootup sequence, create the GPP node, and start everything (omniorb, omnievents, domain, then GPP). I've kicked most of the components to verify softpkgs would get loaded correctly with the new multi-impl patch, but I'll admit a lack of time to really test things or develop an actual "test image" with scripts, etc. using yocto's tooling.