CICD: compile & test reference-contracts in CI workflow for Leap

[spoonincode]

The "Build & Test" workflow run on each PR needs to build and test reference-contracts. This check is primarily aimed at detecting accidental regressions in EosioTester. We probably need to test both "configurations" of EosioTester: in-build-tree & leap-dev.deb. Indeed, I've managed to goof both of these up recently (#403 and #376 being good examples). These two jobs (or potentially a matrix'd job) would run after the Build jobs (such as the Tests/NP Tests/LR Tests jobs do).

In both cases, cdt's .deb must be downloaded via asset-artifact-download-action. The default release/branch to use needs to be easily configurable (see eosnetworkfoundation/eos-system-contracts#39 as a potential solution to this), and also overridable during manual builds. (I'm currently unsure what the default release/branch ought to be: do we fix it at 3.x for now? or just take latest release? or should leap main use cdt main until a leap release branch is created and the default changed then?)

In both cases, reference-contracts needs to be cloned, built, and have its tests run. This needs to have defaults and be configurable much like cdt above, except there is no .deb package from a release -- it may just be based on tags and/or branches so it doesn't use asset-artifact-download-action.

The difference between the two jobs is that one of them consumes the leap-dev.deb and uses it, where as the other consumes the build-dir files. Otherwise they should be functionally similar.

Some refactoring to the workflow may be opted for to improve performance of these new stages (if they are sub 3 minutes, we'd include them in the required tests). For example, right now there is a job dedicated to build leap-dev.deb. Maybe we could co-opt that job to not just build leap-dev.deb but also perform the reference-contracts tests with leap-dev.deb too. Or maybe not -- maybe we opt for separation of these tasks. We also should consider if there is any opportunity for workflow or action reuse between the two repositories. But, it may be that building the reference-contracts is simple enough where that's unnecessary.

[spoonincode]

This has been completed