Add liboni as a submodule

[bparks13]

• To account for the new submodule, update the CMakeLists file with the new folder paths

• Add instructions to the README with how to build the relevant projects and the specific targets for this repo

• Remove any Mac / Linux specific instructions in the README and the CMakeLists file, as neither platforms are currently supported by this plugin

• Fixes Think about how to maintain liboni in this repo #19

• Fixes Compile liboni as static #78

[jonnew]

Please use CMake to create projects within the OE_PLUGIN_onix-source solution, set their build type to static library, and set as dependency of onix-source so that that building that project will trigger compilation of liboni dependency.

[aacuevas]

I am not sure that adding CMake files for liboni inside the plugin is the best path.
Everything that is needed to build liboni should be conatined inside the liboni repo, and only inside that repo. Imagine, for example, that a new liboni version requires changes on the build settings. This would mean having to change the CMake files on the plugin repo, which defeats the purpose of having liboni as a submodule.

I suggest one of these three paths:

1. Create the CMake files for liboni inside liboni
   • This is the most straightforward solution, just create CMake files in liboni that can be used to create project files and included from the plugin CMake
   • This means having duplicated build systems. If we need to change anything, we need to change it in both the original build files and in CMake
2. Move liboni completely to CMake and use it normally to create the build files
   • This removes the downside of option 1
   • However, it means that we are limited by the options/complexity of CMake.
3. Make the plugin CMake call the existing projects on liboni
   • This can be done by use of ExternalProject
   • It keeps our existing build files on liboni while automates its usage on the plugin
   • The syntax and process is a bit complex and it might need some trial and error to get it working well, but that is the CMake way of life

I'd personally use 3, creating proper CMake files for all liboni projects is hard.
One of the interesting details about ExternalProject is that we would't even need to use a submodule for liboni, it can download a git repo on its own. I would still use the submodule, though. It's clearer this way and we have finer control over versions.

[jonnew]

Tested. works well.