Stop using the Lotus `itest` framework for integration tests

# What

I want to raise awareness that most serious source of entangling of Boost and Lotus repos is Boosts use of Lotus `itest` framework for integration tests. These tests work by spinning up simulation nodes of lotus and lotus miner as well as boost in a single process within a go test. Because these nodes are all in the same process, they are all essentially locked to the same go module dependency graph in order to compile. This essentially means that not only is Boost locked to its Lotus version, but it's locked to all of Lotus's sub dependencies. This is why we are currently unable to decouple the version of Lotus's libp2p from Boost's libp2p.

# Proposed solution

I think the simplest way to solve this problem is to run the Lotus & Lotus-miner nodes in docker containers, rather than the same process. It seems like the minimally more complex setup that at the same time unlocks the repos from one and other in terms of sub dependencies. We already have a lot of docker infrastructure in this repo -- my belief is that we could probably assemble something that replaces Lotus itest from this fairly easily. I'd rather avoid an entire testground setup -- testground is more to install and manage on a machine and isn't well integrated with CI, while docker is something almost every dev has on their machine and is very well supported in circle. This would mean that running integration tests locally would get slightly more complicated, but it seems well worth the payoff.