Untangle the macaw-loader submodule knot

[RyanGlScott]

Currently the macaw repo depends on the macaw-loader repo as a submodule dependency. However, the macaw-loader repo also depends on the macaw repo as a submodule. This makes coordinating submodule bumps between the repos challenging, as they sometimes have to be updated simultaneously.

I'd like to propose that we find a way to make this situation more tolerable. Some possible ideas for doing so:

1. Cut the submodule dependency knot by removing macaw's dependency on macaw-loader, thereby removing the macaw-loader submodule dependency from macaw. This would require changing some code in macaw to avoid the use of macaw-loader, however. In some cases, this would impact the public-facing API, such as in macaw-ppc and macaw-refinement.
2. Bring the macaw-loader packages into the macaw repo. This would involve some amount of churn for downstream libraries, but it could be done.
3. Something else?

[travitch]

I'm happy to merge it in. Id like to think about the API a bit, but maybe we can just mark it unstable and refine it over time

[kquick]

I also like option 2: merging in macaw-loader. IIRC, it wasn't originally a circular dependency until we merged some of the other macaw repos together.

[RyanGlScott]

Another unfortunate consequence of doing this is that git submodule update --init --recursive will go into an infinite loop, as reported in GaloisInc/saw-script#2065.