Move translations files (.lcl) out of the GitHub repo

This is an infrastructure change, originally from: https://github.com/dotnet/project-system/issues/7921

### Move translations out of the GitHub repo
Based on the way that OneLocBuild is designed, the `lcl` files shouldn't even be in the repo. These are files used by the localization team's internal system to track localization data in our repo. Originally, I had the `lcl` files out of our repo; however, this didn't work. The `lcl` files were put into a repo (created by the localization team) that had its own pipeline associated with it, where it would produce a package. This package would be used by the OneLocBuild task, downloading this package and extracting it. When that extraction would occur, the path length it created was beyond the standard Windows path length and would fail. I tested this multiple times by renaming files and moving things, and there were many files that caused this situation to occur. I *believe* this issue to be fixed now, but that would need to be confirmed.

The greater idea (as mentioned in my [gist](https://gist.github.com/MiYanni/d291e98f7c53b9fed912e82a0e43b28d)) would be that no localization information is contained within our repo. Instead, we would store both the `lcl` and `xlf` files in a separate repo (likely internal). This makes our PRs to this repo easier as string changes won't generate a bunch of `xlf` files into the PR. Instead, the `official.yml` build pipeline (on PR merge) would create the `xlf` files (*English only*). These files would be sent as a PR to the separate repo as part of the pipeline. After the build is complete, if there are any localization changes, the OneLocBuild task would also create a PR with the `xlf` files (*non-English*) to that repo. These PRs should auto-merge in a majority of cases. When we get translations back from the localization team (a PR with `lcl` files), those too would merge into this separate repo. Since this is part of our `official.yml` build, when we get the package from the separate repo, it will contain whatever current translations via the `xlf` files from that repo at that time. So, we'll still get translated DLLs.

One of the downsides of this approach is debugging translation issues in our repo becomes more difficult, and non-accessible to outside contributors. However, at this time, a majority of our translation issues come from the internal testing team. I believe removing the localization files reduces development friction and makes external contribution easier. Now, people wouldn't have to build locally to make sure the new `xlf` files get produced, as they would never need to be aware of this process at all. It is basically pushing localization down 1 layer in our build processes to no longer make it front-facing or an impediment for development. It reduces the number of PRs we need to review since the internal repo would simply auto-merge. We require external repos to always have a human reviewer. However, if all PRs for a repo (the internal one) are generated by tooling, there's no human interaction needed. It is only used as a storage location with change tracking. Lastly, because of how the OneLocBuild process works, we shouldn't be modifying the `lcl` or `xlf` files by hand at this point. This desyncs the information with the translation team's service. Thus, they don't need to belong here in this repo.