Don't remove unused qubits in default compilation pass

[cqc-alec]

This causes sometimes-surprising differences with other backends. To get around the problem of QASM insisting on contiguous zero-indexed registers, can we omit this step and relabel the qubits including the blank ones?

[sjdilkes]

This solution would mean we're rejecting valid Circuits that only need to call remove_blank_wires. The inconsistency Dan found is due to the stored Architecture referring to Node as "fcNode", while the current Quantinuum compilation both relabels them to "q", and doesn't update the Compilation maps to reflect this. Updating the connectivity graph generating Architecture classes to allow custom Node labelling https://github.com/CQCL/tket/pull/796 and moving the relabelling pass into the c++ to allow the maps to be updated https://github.com/CQCL/tket/pull/799 was my planned solution.

*The analogy I've been working with for removing wires is as with Routing for other algorithms, where we remove empty wires and add ancillas to find a good solution.

I think this works around Dan's problems sufficiently - but can update it to just not remove empty wires if that is preferred* though I don't think this is a better solution.

[cqc-alec]

I thought the issue was that Dan wants to run the default compilation pass on circuits that contain blank wires and for the result to still contain blank wires. However I'm not sure that's a reasonable request. Maybe having remove_blank_wires as an option defaulting to True would also work.

[daniel-mills-cqc]

Just to give my view as a user, there are a couple of themes which guide my requests:

• As someone who builds software on top of pytket, I prefer the backends to behave as similarly as possible. We have hacked around it a few times but only after time spent debugging to find the differences, and it would be neater not to.
• When designing experiments I prefer to see errors and warnings, rather than have pytket default to 'correcting' my 'mistakes'. This might be a benchmarking edge-case, but there are a lot of us doing benchmarking.

I think maybe these both apply here? Many thanks for looking into this!