Add CI pipeline to hw bridge repo

[wmmc88]

We need some ci pipeline integrated into the hw bridge repo so that people can merge without an admin needing to force merge. Currently, both fw and sw repos are pinned to a certain commit on the bridge repo.

Extra care needs to be put into this pipeline. I think that whenever there's a pr to the bridge repo, there should be pipelines run to build it against master of sw and fw. This way, we guard against backwards compatibility breaking changes.

Sometimes, things need to break backwards compatibility, and for good reason. A github admin would be able to force merge, but I think that two things need to happen:

• There should be a way of logging which commits break backwards compatiblity
• On MRs with backward-compatibility breaking changes, we should have a way to run CI against a special commit of both SW and FW to prove that the fixes to the breaking changes are implemented and working. These should be commits that are in a PR stage and have passing pipelines in their respective repos.

The idea behind the second point, is that if we ever have a breaking change, we have synced prs to sw, fw, and bridge at the same time.

[wmmc88]

Here's an idea for implementation:

Have the 2 pipelienes that run against master of sw and fw. These two should pretty much match(in terms of what they test) the ones in sw and fw repo . These two pipelines should be marked required to pass for merges.

There should be 2 other pipelines that automatically run sometimes. We could have a file in the repo that has a table of the commits of a breaking change, and their matching sw and fw pr's. The two pipelines(one for sw and one for fw) can check if the thats being run contains commits in the breaking change list that haven't been merged to master. if there are, then run the optional pipeline against the the fw and sw commits listed in the table file.

[wmmc88]

@cindyli-13 @niiquaye

I found this in some ros2 ci action:
https://github.com/ros-tooling/action-ros-ci#interdependent-pull-requests-or-merge-requests

Someone should look into how they do it, and how we can create something similar to simplify and "robustify" our pr process