Fix release jobs post-0.25.1 release

[mtreinish]

Summary

This commit fixes 3 issues identified during the 0.25.1 release. The first is that the name of the qiskit package build/publish job was invalid in azure pipelines. The - character is not valid and throws an error when the release is triggered. The second issue is that the qiskit package job is triggered at the same time as all the qiskit-terra package build/publish jobs. However, the qiskit package is very quick to build while the qiskit-terra jobs take some time so qiskit will be published first and qiskit-terra second. This will result in a small period when qiskit is uninstallable because it depends on a yet unpublished release of qiskit-terra. To address this the build artifact deployment is split into 2 stages, the first builds the qiskit-terra precompiled binary wheels and publishes those to pypi first. The second stage builds the qiskit-terra sdist and the qiskit package. This means users will always have a working install when they do pip install qiskit. The final fix is the path for the qiskit package's build artifacts was incorrect. This caused the job to fail because it could not upload the artifacts for local download or to pypi.

Details and comments

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 5902400014

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 4 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.01%) to 87.257%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
crates/qasm2/src/lex.rs	3	90.63%

Totals
Change from base Build 5902014500:	0.01%
Covered Lines:	74352
Relevant Lines:	85210

---

💛 - Coveralls

[jakelishman]

I guess the downside to this is that a failure to upload any single wheel will cause the sdist job not to be run. We've not generally had a problem with this in the Azure-managed sections of the deployment, but we've frequently used the parallelisation of the builds in the tier-2 and tier-3 supported platforms and let PyPI bounce already-successful packages during a re-run. If the sdist run failed for any reason, we'd not easily be able to retrigger it in this form without rewriting the file to remove the dependency.

That's probably fine as a compromise, just mentioning that it's a decision we're implicitly making here.

[mtreinish]

I think it's ok as a compromise, I think optimizing for minimizing the user facing impact of a failure is more important here. Pushing a throwaway branch to manually retrigger the sdist build isn't that high a burden IMO (I had to do it during the 0.25.1 release already :) )