Ensuring instruction labels are strings when provided to the Instruction constructor.

[upsideon]

Summary

Fixes #7667 by adding a type check to the Instruction constructor which will raise a TypeError if the label parameter is provided, but not of type str. Per the associated issue, this guarantees that an informative exception is raised for labels of an invalid type at instruction creation time rather than when the label is later processed by print or draw.

Details and comments

Note that this pull request also adds a test for the type check that already existed for the label setter, but which was not under test coverage. I thought it prudent to add this test so that if our type checking rules change for labels in the future, we immediately know via a test failure that a change needs to be applied in both locations.

[CLAassistant]

All committers have signed the CLA.

[coveralls]

Pull Request Test Coverage Report for Build 2186209636

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.005%) to 83.946%

---

Files with Coverage Reduction	New Missed Lines	%
qiskit/circuit/controlflow/if_else.py	1	96.24%

Totals
Change from base Build 2185891955:	0.005%
Covered Lines:	54215
Relevant Lines:	64583

---

💛 - Coveralls

[jakelishman]

Thanks for looking at this and making the PR - it looks good! I left a couple of minor comments, but nothing serious.

Please could you also add an "upgrade" release note for this - the instructions should be in the contributing guidelines. We just need to explain in one sentence that instruction labels will now be type-checked on creation.

[upsideon]

Thanks for the feedback, @jakelishman! I've applied each of the requested changes.

[upsideon]

@jakelishman Do you think you'll have an opportunity to give this pull request another review?

[jakelishman]

Sorry for the delay! This looks good to me now, and thanks for pinging me so it didn't get lost.

[jakelishman]

We're getting some test failures here after this change, but I actually think that this PR is turning up buggy behaviour from existing code, and isn't the problem itself. I'll have a look into it, and see what's going on there.

[upsideon]

Thank you for the additional review and thank you for looking into the test failures! Feel free to let me know if you'd like any help.

[jakelishman]

The issue turned out to be that a particular couple of automated tests for gates were guessing on how to construct everything, and in some cases it was getting it wrong and passing an extra parameter that was getting put in the label slot. This PR then made that a failure (as it should be), so we saw a test failure. I've pushed a commit that works around the issue (the automated instantiation is still pretty questionable), so this should be good to go now. Thanks!