Feature/docker branch tagging

[akoerner1]

This PR contains several major changes to the build system.

1. File system path normalization working towards the goal of enabling catkin build to also work the e.g., catkin build .

• All paths referenced within the entire project need to be relative and identical weather inside a docker context or outside a docker context.
• This is specifically important for CMake related paths
• The basic structure is package/package with the first level containing docker build or runtime context when necessary.

2. Due to concurrency issues with the catkin workspace the "create_catkin_workspace" target/recipe was split into two targets namely, initialize_catkin_workspace and create_catkin_workspace

• The distinction between both targets is that the initialize_catkin_workspace target only calls the catkin workspace creation script if there is not already a workspace. This speeds up subsequent runs of adore-cli

3. Splitting each module's makefiles into two separate files. As an example in adore_if_ros there is a Makefile and adore_if_ros.mk. All modules follow this pattern.

• The Makefile within each module acts as an internal interface e.g. you can navigate to the module and run any make target/recipe directly on the module
• The .mk file with the same name as the module itself, adore_if_ros.mk for example, acts as the external interface to the module. This file can be imported into and downstream project to gain access to relevant module interfaces such as build and clean et cetera.
• To consume a given module you include it into downstream Makefiles:

...
include adore_if_ros/adore_if_ros.mk
...
test_target: build_adore_if_ros

4. Most modules inherit the make_gadgets(git) project which means 'make help' works on every module.

• Every module provided the 'help' target
  
• every module provides the 'image_&ltmodule name&gt' target which provides the docker repository and tag that was used when running docker build
  

6. The major feature of this PR is Docker branch tagging

• Each docker context build by a given project uses a docker normalized (the character set permitted in git branches is larger then what is permitted in git hashes) git hash or branch as the docker tag as shown in the attached figure:
  
  -Any downstream docker context that needs to consume a given image can then provide the tag as a build argument as follows:
  
• In the case of adore_if_ros this variable is provided by adore_if_ros.mk

7. Added a help command for the adore cli:
   
8. Simplified getting started. To get a running system now you can simply clone the repository and run the cli:

git clone --recurse-submodules -j8 git@github.com:eclipse/adore.git 
cd adore && make cli

• The whole system will be built, the runtime contexts will be built as well as the adore-cli context

9. adore-cli user within the adore-cli context can run sudo for apt, apt-get and aptitude.

[akoerner1]

This will need to be modified to change the ross master to another host. I recommend somehting such as:

      - ROS_MASTER_HOST=${ROS_MASTER_HOST:-127.0.0.1}
      - "ROS_MASTER_URI=http://${ROS_MASTER_HOST}:11311"
      - "ROS_HOSTNAME=${ROS_MASTER_HOST}"

Then the ros master host can be arbitrarily set as an environment variable or it defaults to 127.0.0.1 during docker compose run aka adore-cli.