Restructuring demos (#531)

Summary:
Pull Request resolved: https://github.com/pytorch/executorch/pull/531

-----
## Confusion arising from the current code structure:

Reference to current code structure: https://github.com/pytorch/executorch/tree/main/examples

The current code structure under `executorch/examples` mixes different levels of detail. For instance, the directories `backend/`, `quantization/`, and `export/` are intended for component-level demo code, such as showcasing quantization/export/delegation workflows or providing sample backend/quantizer/partitioner implementations. Assembling them to create a AOT path should not belong to any of it. However, the current structure combines recipes and individual components:
  - All contents of `backend/` are exclusively tailored for [xnnpack](https://github.com/pytorch/executorch/tree/main/examples/backend).
  - [export+delegate+composite](https://github.com/pytorch/executorch/blob/main/examples/export/export_and_delegate.py) and [bundled program example](https://github.com/pytorch/executorch/blob/main/examples/export/export_bundled_program.py) are placed in `export/`
  - Different runtimes are placed haphazardly., with items like [executor_runner](https://github.com/pytorch/executorch/tree/main/examples/executor_runner), [bundled_executor_runner](https://github.com/pytorch/executorch/tree/main/examples/bundled_executor_runner), and [xnn_executor_runner](https://github.com/pytorch/executorch/tree/main/examples/backend)
  - Backend-specific demos are scattered in the top-level directory, such as [arm's demo](https://github.com/pytorch/executorch/tree/main/examples/arm) and [partitioner/quantizer demo](https://github.com/pytorch/executorch/tree/main/examples/example_quantizer_and_delegate)

Issues that are not directly tie to code restructuring but will need to be addressed as well. **Non-functional code/demo** (fix or hide):
  - [Unit tests](https://github.com/pytorch/executorch/tree/main/examples/export/test) under the `export/` directory are not runnable in the OSS environment.
  - The [example_quantizer_and_delegate](https://github.com/pytorch/executorch/tree/main/examples/example_quantizer_and_delegate) is not functioning and should be rectified or hidden.
  - The [arm's demo](https://github.com/pytorch/executorch/tree/main/examples/arm) is not runnable directly w/o additional guide.

-----

## Proposed code structure:
organize demos in a way that is easier for users to understand how pieces are put together to create an e2e experience. We can go with this "vertical" structure if we could come up and agree on guidelines of whether a new demo should be considered as "adding a new demo" or "extending an existing demo".

The purpose is to prevent randomly dumping demos in the top-level executorch/examples folder with boilerplate code. While this doesn't violate the rule of structuring demos vertically for user understanding, , but it literally has no structure at all, and it will quickly grow of out our maintenance.

In my opinion, it would make sense to consider the following cases as **"adding a new demo"**:
  1. Demo of a new 1st/3rd party backend, e.g. portable (default backend), xnnpack, arm, coreml, etc.
  2. Demo of toolings, e.g. selective build, productivity sdk, etc.
  3. Target specific apps, e.g. playground apps for Android/iOS/Embedded

The rests will be considered as **"extending an existing demo"**, for example:
  - Demo of composibitlity, e.g. delegate and composite, whole/partial graph lowering, custom ops
  - Demo of specific components, e.g. quantization workflow, 2-stage export flow, example quantizer/partitioner, etc.

After PTC we will spend more efforts on expanding and polishing the two major 1st-party demos (`examples/portable/` & `examples/xnnpack/`) we own in the long run. Maybe `examples/sdk` as well.

So with the guidelines, the new top-level structure will looks like:

```
executorch/examples/
├── README.md    # top-level description for demos and folder structures
├── models/
├── xnnpack/     # 1p e2e
├── portable/    # 1p e2e
├── arm/          # 3p backend e2e
├── qualcomm/     # 3p backend e2e
├── apple/        # 3p backend e2e
├── third-party/    # for the short-term, we can assume a centralized place for all third-party libs required by demos, e.g. sam, llama, etc.
├── selective_build/
├── sdk/
├── demo-apps/
└── utils/               # future
```

If we zoom in to `examples/portable/`, it will look like:
```
executorch/examples/portable/
├── executor_runner/
├── bundled_executor_runner/
├── custom_ops/
├── scripts/
│   ├── export_and_delegate.py
│   ├── export_bundled_program.py
│   └── export.py
├── test/
├── __init__.py
├── utils.py
└── README.md
```

If we zoom in to `examples/xnnpack/`, it will look like:
```
executorch/examples/xnnpack/
├── quantization/
│   ├── example.py
│   ├── TARGETS
│   ├── test_quantize.sh
│   └── utils.py
├── __init__.py
├── aot_compiler.py
└── README.md
```

Reviewed By: mergennachin

Differential Revision: D49714823

fbshipit-source-id: fd3c2339057e9a3d7dc1d69ec7ede1287f081d8f