feat(biome): monorepo support #3972

The biome [documentation](https://biomejs.dev/guides/big-projects/#use-multiple-configuration-files) mentions that 

> When you use Biome’s features - either with the CLI or LSP - the tool looks for the nearest configuration file using the current working directory.
>
> If Biome doesn’t find the configuration file there, it starts traversing upwards the directories of the file system, until it finds one.

I think it makes sense to follow this recommendation, so we can have proper monorepo support. Currently, in a monorepo, a new client is started for each `biome.json` (similar situation as #3910), which is unnecessary, since biome supports monorepos [natively](https://biomejs.dev/guides/big-projects/#monorepo) (as of v2). The alternatives I have considered aren't as robust.

The first concern is searching for a `biome.json` to be set as the root. Unfortunately, that's cumbersome: the documentation recommends flagging the files that _aren't_ the root. That means we _can't_ use `root_markers_with_field` to search for a file that **is** the root. The proposed solution solves this issue by behaving as the CLI would.

Secondly, we have to check if a project uses biome, via `package.json` and friends, which is the fallback behavior. I've considered using #3955's approach of lock files, but since it would require searching for the field 'biome' within lock files (which are often thousands of lines long), I was worried about causing a performance hiccup.

0 files changed, 0 insertions, 0 deletions