Execution framework modularization

## Abstract

The execution framework the semantic tests run in is not customizable and relies on internal compiler interfaces. Here, we'll describe an approach that makes it possible to compile using any executable that implements `solc`'s standard JSON input and output interface. With this, we can use `solc` by default, and also unlock more complex compilation stage setups, as long as they behave like `solc`.

## Motivation

It would be very beneficial, if one could customize the compilation stage for semantic test executions. This would allow e.g. plugging in the GreY pipeline and test the produced bytecode, but also replacing the internal compiler interface aka. `CompilerStack` with `solc`.

## Specification

The main idea is to define a common interface for compilers that can be plugged into the compilation stage in semantic test executions. `solc` provides an JSON input-output interface already, so this will be used as the common ground to support more complex setups.

### Usage

With this implementation, it will be possible to specify a custom compiler module via `soltest`:

```
soltest --solcPath /usr/bin/solc
```

If specified, all semantic tests will be compiled using that executable. If not, we will fall back to `solc`.

### Implementation

#### Phase 1: Modularize compilation stage

In phase 1, the current implementation will be improved such that the compilation stage allows switching the compiler by introducing an universal compiler host. This defines an interface that compiler adapters must implement in order to be hosted. It will also use newly introduced common compiler input and output types.

Right now, the framework uses the internal `CompilerStack`. In the new implementation, this will be stored in an adapter that can be hosted by the framework.

#### Phase 2: Plug in `solc`

Next to the adapter for the internal `CompilerStack`, we will introduce one that can interact with `solc` via IPC. This adapter can be used for every compiler module that implements `solc`'s standard JSON input and output interface. It will use the common input and output types defined in the previous implementation phase.

##### Benchmarking

There have been some concerns raised with regards to performance. When using `solc` we'll introduce some overhead (JSON serialization, IPC) that will affect performance. We'll need to benchmark both adapters against each other.

> If performance is an issue, we might need to re-evaluate the overall approach and research alternative solutions. We could at least implement one part of this proposal and add an adpater for `StandardCompiler` (which is at least a bit more up in the stack) first. And only explore ideas that allow customization individually.

##### Remove `CompilerStack` adapter

If there are no major blockers (mainly with regards to performance), we'll remove the adapter for the internal compiler and only use `solc` from now on instead.

#### Phase 3: Allow compiler module selection via `soltest`

In this phase, `soltest` CLI should be modified to take an addtional argument for the compiler module. Here, we'd should also run first experiments with more complex compiler modules that mimick `solc`.