Explain effort to encode project data (like default build flags) in version control next to build targets

### Description of the feature request:

We've been working on something called `PROJECT.scl`. This is a source of truth for project information, checked in version control next to build targets. It can conceptually contain various kinds of information. But we're focusing now on declaring "correct" build flags for a project, or auto-applying default flags on a per-project or even per-target basis..

For example:

1. `$ bazel build //myproject:foo`
1. bazel walks up `//myproject`'s package path and finds `myproject/PROJECT.scl`
2. `myproject/PROJECT.scl` declares that all targets in `//myproject` should by defualt set `-c opt --//myproject:custom_flag=foo`
3. So `$ bazel build //myproject:foo` automatically adds `--c opt --//myproject:custom_flag=foo`

Or:

1. `myproject/PROJECT.scl` defines `--scl_config=some_supported_config` which sets another set of build flags
2. `$ bazel build //myproject:foo --scl_config=some_supported_config` automatically sets those flags
3. This is similar to bazerlc / `--config` with the important distinction that this is *project-scoped*: `//myproject:foo` can declare completely independent settings vs `//yourproject:bar`. The right settings automatically apply to the right target regardless of who's building on what machine from what repo. `bazelrc`, by contrast, depends heavily on the user and the main repo, and basically doesn't map well to project granularity.

This is intended to better support the idea that `$ bazel build //foo` "just works", regardless of where or how or from whom it's invoked. This opens up all kinds of interesting possibilities like easily reproducing CI at the command line, more portable CI because setup is Bazel-internal and therefore detached from whatever system invokes it, library maintainers can build projects that depend on them, less need for "how to build" project docs, better remote cache hit rates, cheaper builds, more cache pre-warming. and easier refactoring.

It also supports possibilities like [memory-efficient incremental builds](https://bazel.build/advanced/performance/memory#trade-flexibility) and [faster / more memory-efficient project feature flags](https://bazel.build/advanced/performance/memory#trade-flexibility)

BazelCon 2024 showed interest in these ideas. I promised to follow up and support discussion. This bug report is a start but there are a lot of important details we need to make sense of. Like how (or if) this fits with `REPO.bazel` or `MODULE.bazel`, which flags this can and can't apply to, and new build paradigms we could imagine like `$ bazel build ///foo%entire_ci_project`.

I'll expand this all out in a proper Github discussion.

### Which category does this issue belong to?

_No response_

### What underlying problem are you trying to solve with this feature?

`$ bazel build //foo` "just works" without having to know which flags to set.

Even more portable and reproducible builds.

### Which operating system are you running Bazel on?

n/a

### What is the output of `bazel info release`?

n/a

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

n/a

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
n/a
```

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

[history of recent commits](https://github.com/search?q=repo%3Abazelbuild%2Fbazel+project.scl&type=commits)