Upstream the ONNX importer.

[stellaraccident]

This is part 1 of 2, which will also include upstreaming the FX importer. I started with ONNX because it forces some project layout updates and is more self contained/easier as a first step.

Deviating somewhat from the RFCs on project layout, I made the following decisions:

• Locating the onnx_importer.py into torch_mlir.extras as Maks already has opened up that namespace and it seemed to fit. Better to have fewer things at that level.
• Setup the build so that the root project only contains MLIR Python and pure Python deps (like the importers), but this can be augmented with the projects/ adding more depending on which features are enabled.
• The default build continues to build everything whereas in TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS=1 mode, it builds a torch-mlir-core wheel with the pure contents only.

onnx_importer.py and importer_smoke_test.py are almost verbatim copies from SHARK-Turbine. I made some minor local alterations to adapt to paths and generalize the way they interact with the outer project. I expect I can copy these back to Turbine verbatim from here. I also updated the license boilerplate (they have the same license but slightly different project norms for the headers) but retained the correct copyright.

Other updates:

• Added the ONNX importer unit test (which also can generate test data) in lit, conditioned on the availability of the Python onnx package. In a followup once I know everything is stable, I'll add another env var that the CI can set to always enable this so we know conclusively if tests pass.
• Moved the ONNX conversion readme to docs/.
• Renamed CMake option TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS -> TORCH_MLIR_ENABLE_PYTORCH_EXTENSIONS and inverted the sense. Made the JitIR importer and LTC options cmake_dependent_options for robustness.