Remove buck dependency from CMake build

[GregoryComer]

🚀 The feature, motivation and pitch

CMake builds currently rely on buck under the hood to generate source lists for each target. Buck is not available on all platforms and is the source of friction when building ExecuTorch. We've discussed and are largely aligned on the goal to remove the buck dependency from CMake, either by splitting source lists into a format that can be shared between buck and CMake, or by globbing.

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

cc @larryliu0820 @mergennachin @byjlw

[swolchok]

Here's my plan to execute on this. PR counts are estimates just to give an idea of what to expect.

1. Create a PyTorch-like build_variables.bzl that is isomorphic to the current contents of executorch_srcs.cmake. Use (i.e., copy/paste/modify into ExecuTorch repo; it's short enough) PyTorch's append_filelist CMake function to ingest it. At CMake time, enforce that the filelists in build_variables.bzl are identical to the ones in the Buck-generated executorch_srcs.cmake. (1-2 PRs)
2. Make build_variables.bzl the canonical way that the Buck-driven build finds all files it mentions. This will entail refactoring/splitting the filelists it contains to reflect Buck's finer-grained view of the world and then including (very simple) Starlark code in build_variables.bzl that reassembles the CMake-isomorphic set of filelists. (probably 1 PR per affected Buck target, many in total)
3. Switch over from executorch_srcs.cmake to the filelists from build_variables.bzl and stop running Buck during builds. (1 PR)
4. Clean up OSS-only Buck artifacts (CI scripts and workflows, shim files (keeping these as we want to run buck2 in CI to ease internal import process), installation, etc.). (small number of PRs)
5. Clean up executorch_srcs_from_build_variables_bzl.cmake; directly produce CMake variables using append_filelist rather than writing out a .cmake file and reading it back in. (0-1 PR)
6. (out of scope) Make the CMake target graph finer-grained and closer to the internal Buck graph.

If we wanted to be extremely aggressive, we could move (2) after (4), but I don't see any particular reason to rush to remove Buck from the process before the replacement setup is properly "livable".