WIP: Always build a CPU variant

[basnijholt]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[wshanks]

For context, I see that the patch here is mirroring Qiskit/qiskit-aer#2029. This would be kind of a large patch to carry downstream, but I hope it can be accepted upstream.

[wshanks]

I noticed while looking at the tests for #30 that the CPU code is always built, but it is built into the same binary as the GPU code and importing that binary probably leads to an error if you don't have the CUDA libraries installed. From the tests, it seems like you can use the CPU backend if you have the CUDA libraries installed though, even if you don't have a GPU. The default behavior might not be as convenient for you though as it is with Qiskit/qiskit-aer#2029 where it tries the GPU import and moves on to the CPU import if it fails. Currently, Aer might just try to use the GPU and fail if you don't ask for the CPU backend explicitly when using the GPU build.