Fix default wire mapping and QPU program compilation and add support for parallel execution

[MarquessV]

This addresses #123 in a 3 ways:

1. Default wire mapping behavior

By default, we were using [0, n) as the wire numbers for an n-qubit device, but qubits on a real QPU aren't always addressed in this way. Instead, we let pyQuil tell us what the qubits on the device are and build the wire map from that. By default, the user wire labels will map to a device wire label 1-to-1, that way users who want to address them, can do so using the values directly from the our QPU topology metrics and diagrams.

2. Qubit measurement

Measurements will now use the wire mapping to generate MEASURE statements for every Qubit to readout instead of assuming [0, n). Like (1), this is important for real QPUs, which don't always address qubits sequentially.

3. Use protoquil for program compilation targeting QPUs

By default a program compiled by quilc will use the full quil spec to generate native quil. However, not everything in the quil spec is supported by our QPUs, so quilc also supports building a program using protoquil, a subset of quil that is compatible with a QPU.

Our QPU devices now set the protoquil flag when compiling to avoid generating a program that might not run on a real QPU.

This also adds support for parallel execution using threadpools to run jobs in parallel. This works for both the QVM and QPU device and can greatly improve execution speed.

[MarquessV]

@AlbertMitjans Can you take a look at this? Thanks! 😄

[trbromley]

To make sure I understand, does this mean that the user can pass any wires and they'll be mapped to the device wires, or that the user must use the appropriate wires for the device?

[MarquessV]

Per offline discussion, closing this in favorite of separate PRs for the wire mapping fix and the parallel processing improvement.