Fix circular dependencies by making ofrak_angr and ofrak_capstone optional for ofrak_core tests

[ANogin]

• I have reviewed the OFRAK contributor guide and attest that this pull request is in accordance with it.
• I have made or updated a changelog entry for the changes in this pull request.

One sentence summary of this PR (This should go in the CHANGELOG!)
Optmizes the build of the --target=development docker containers by removing the ofrak_core "forward" test dependencies on ofrak_angr and ofrak_capstone

Link to Related Issue(s)
Fixes #419

Please describe the changes in your request.
#226 introduced an unfortunate issue (which I discovered using PR #218 - IMHO we really out to land that one, and use in CI) - when the docker build runs make develop, it would first go to ofrak_core, where the "test": "ofrak_angr"] dependency would cause it to download ofrak_angr from PyPI, then it would go into ofrak_angr and then the make develop there would overwrite the downloaded one with the local one (and similar with ofrak_capstone). With #417, this means that not only the ofrak_angr itself is downloaded from PyPI, but also the angr itself and all its dependencies installed in base.Dockerfile are updated to the versions required by the ofrak_angr from PyPI. Then make develop would put them all back.

A potentially even bigger issue is that the ofrak-ghidra.yaml container would use the ofrak_angr and ofrak_capstone from pypi, not the latest, so the testing in CI would not necessaily be accurately representative of what is actually going on!

This appempts to fix the issues by:

• Removing the extra dependencies
• Skipping the test that depend on ofrak_angr and ofrak_capstone when those are not installed
• Using a new ofrak-angr-ghidra.yml container for all tests

Anyone you think should look at this, specifically?
@whyitfor

[whyitfor]

@ANogin, please see comments -- once this is done, we can merge this in.

The comments suggest a short-term work-around to this issue.

Longer term, I'd like to have the following true:

1. ofrak-dev.yml allows a user to build, test, and use the core ofrak components only. We need to remove the ofrak_angr and ofrak_capstone test dependencies here.
2. ofrak-ghidra.yml allows a user to build, test, and use ofrak with Ghidra.
3. ofrak-angr.yml allows a users to build, test, and use ofrak with angr.

[ANogin]

• ofrak-dev.yml allows a user to build, test, and use the core ofrak components only. We need to remove the ofrak_angr and ofrak_capstone test dependencies here.

Isn't that what ofrak-core-dev.yml is for?

[whyitfor]

• ofrak-dev.yml allows a user to build, test, and use the core ofrak components only. We need to remove the ofrak_angr and ofrak_capstone test dependencies here.

Isn't that what ofrak-core-dev.yml is for?

Sure, ofrak-core-dev.yml allows a user to build, test, and use the core components only.

[ANogin]

@whyitfor does this require a Changelog entry?

[whyitfor]

@whyitfor does this require a Changelog entry?

I think so. I'm generally thinking the following:

1. A Fixed entry here saying that ofrak drops circular test dependencies.
2. We should bump (in changelog and in setup.py) ofrak's version to 3.3.0rc1. In the changelog, this will just change the Unreleased line. The idea behind this is then we can use these rc versions internally to specify "this is the unreleased version of ofrak I'm using" (this can be helpful for projects that rely on ofrak "master" -- they can specify through versioning that they are on an older version of master.

@rbs-jacob, does this make sense to you?

[rbs-jacob]

@rbs-jacob, does this make sense to you?

Yup, sounds good to me. I think bumping versions before release is something we probably should have been doing the whole time, but I don't think anyone thought of it until recently.

[whyitfor]

LGTM