First pass at getting architectured builds working

[charlesbluca]

Rationale for this change

When attempting to import the generated conda nightlies on a non-Linux OS, we get an error message looking something like:

>>> import datafusion
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/charlesb/mambaforge/envs/test-datafustion-packages/lib/python3.10/site-packages/datafusion/__init__.py", line 28, in <module>
    from ._internal import (
ImportError: dlopen(/Users/charlesb/mambaforge/envs/test-datafustion-packages/lib/python3.10/site-packages/datafusion/_internal.abi3.so, 0x0002): tried: '/Users/charlesb/mambaforge/envs/test-datafustion-packages/lib/python3.10/site-packages/datafusion/_internal.abi3.so' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/Users/charlesb/mambaforge/envs/test-datafustion-packages/lib/python3.10/site-packages/datafusion/_internal.abi3.so' (no such file), '/Users/charlesb/mambaforge/envs/test-datafustion-packages/lib/python3.10/site-packages/datafusion/_internal.abi3.so' (not a mach-o file)

I'm fairly sure this is due to the package being built as noarch right now, and I think can be resolved by specifying an architecture-dependent Rust compiler at build time (though probably won't be able to get full verification on this until we run against conda-forge's CI if we intend to publish there).

What changes are included in this PR?

Modifications to the conda nightly recipe to enable architectured builds of the nightly packages, which should hopefully unblock import errors on other operating systems.

Might also push some temporary changes to roughly verify that things build correctly on Windows/macOS, though was planning to follow dask-sql's practice of only testing builds against Linux.

[andygrove]

I'm not an expert in this area, but the changes look reasonable to me. Thanks @charlesbluca!