To build all with Bazel.

## Background
When putting `pytorch_blade` and `tensorflow_blade` to open source, BladeDISC's project structure gets more complex. Currently we've already had the following essential directories:
- `tao`: TF bridge of BladeDISC
- `tao_compiler`: BladeDISC compiler main executable, **which will be symbolically linked to a directory under `tf_community` and built with tensorflow.**
- `tf_community`: mirroring [tensorflow/tensorflow](https://github.com/tensorflow/tensorflow).
- `mhlo_builder`: PyTorch bridge of BladeDISC, converting TorchScript to MHLO IR.
- `pytorch_blade`: Python API to optimize PyTorch model.
- `tensorflow_blade`: Python API to optimize TF model.

## Our Goal and Current Status
**As we've discussed for a long time and many times, we're moving to MonoRepo with both open source and internal code repository, and use Bazel to build ALL**. Making all in this repo able to build with Bazel would make dependency structure explicit, standard and clean, and help new developers ramp-up smoothly.
In ideal status, one could run a universal preparation script once with necessary arguments, and then `bazel build` or `bazel test` any target from any component.

But there're some obstacles in the way:
1. Components are build independently, even with different build tool. For example:
- `tao` is build with CMake, while `tao_compiler` is with Bazel. It worth nothing that, RAL code is built by both side.
- `pytorch_blade` is build Bazel wrapped by python Setuptools, while `tensorflow_blade` has Bazel calling setuptools.
2. Components usually have their own build script, shell or python, which cuts off Bazel dependency chain.
3. Free-style preparations in these scripts make Bazelization even harder:
- Symbolic linking `tao_compiler` and RAL files to `tf_community` directory.
- Installing 3rd party library, wheel or others: https://github.com/alibaba/BladeDISC/blob/70ecc07449ade0450fbd0f0f58494c38e683c5b3/pytorch_blade/ci_build/build_pytorch_blade.sh#L34 or https://github.com/alibaba/BladeDISC/blob/a0d60f9f258052c13f1e45f365e451075a7db937/scripts/python/common_setup.py#L302

## Approaches
### 1. Build `tao` with Bazel.
The `tao` directory is currently built with CMake. Converting CMake to Bazel is non-trivial but still possible. But for code of RAL, which is build both on bridge side and compiler side makes things complex. RAL code is build with CMake on bridge side and with Bazel on compiler side under `tf_community` directory. The BUILD file of RAL code load `tf_community`'s rules which won't be available on bridge side. Because bridge just has include files and shared libraries of give host tensorflow. https://github.com/alibaba/BladeDISC/blob/a0d60f9f258052c13f1e45f365e451075a7db937/tao_compiler/mlir/xla/ral/BUILD#L3-L5
There maybe several soluctions:
1. Make that `BUILD` file neutral and just load standard Bazel rules, so that it could be used for both bridge and compiler side. Same source files can be compiled into different target for each side. It's also possible to setup an option specifying which side is being building, and use `select` to switch between dependencies from `tf_community` and host tensorflow.
2. Only expose `filegroup` target from RAL directory, each side write `cc_library` target in `BUILD` file under their own directory.

### 2. Extend `common_setup.py`
If `tao` is built with Bazel, all DISC components could expose Bazel targets (may or may not be in single workspace)! Upper-level components like `pytorch_blade` and `tf_blade` could reference those targets and move on there own building.

`common_setup.py` is used to do preparations before build symbolic linking and OneDNN installation before building DISC. So when building any component that depends on DISC, `common_setup.py` should be called in advance:
https://github.com/alibaba/BladeDISC/blob/70ecc07449ade0450fbd0f0f58494c38e683c5b3/pytorch_blade/ci_build/build_pytorch_blade.sh#L45
If we extend `common_setup.py` a little bit, setting environment variables in `build_pytorch_blade.py`, pytorch_blade will be free from extra build script( as for the relationship of Python setup tools and Bazel, see open questions). If so, why not just make `common_setup.py` a global setup step for this whole project, like the [configure](https://github.com/tensorflow/tensorflow/blob/master/configure) script in tensorflow.

### 3. Make DISC a Bazel Workspace out of tf_community
We've had pretty many Bazel workspace now, from an achitecture view, it's natural to have a single Bazel workspace for all of `tao_compiler`/`tao`/`mhlo`, which make up DISC. Pulling `tao_compiler` out of `tf_community`'s workspace is the key to achieve this goal. I have to admit that it not a very urgent task and we may have challenges if many `tf_community` internal targets are referenced by `tao_compiler`. IREE has [similar works](https://github.com/google/iree/blob/54203503214147f8e356e1e78ccf5b34be1c703e/integrations/tensorflow/iree_tf_compiler/BUILD#L42), may that help.

These are just immature thoughts of my own, your comments pls ~

## Open Questions

1. The relationship of Python setup tools and Bazel?
`pytorch_blade` is build Bazel wrapped by python Setuptools, while `tensorflow_blade` has Bazel calling setuptools.

Start by reading tao_compiler/mlir/xla/ral/BUILD, pytorch_blade/ci_build/build_pytorch_blade.sh, and scripts/python/common_setup.py, then compare the tao CMake and tao_compiler build paths. The issue is complete only when the DISC components can use the intended shared preparation and Bazel build/test workflow without broken dependency boundaries.

Written by the indexing model from the issue text.