Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Bumps [@eslint/plugin-kit](https://github.com/eslint/rewrite/tree/HEAD/packages/plugin-kit) from 0.3.2 to 0.3.3.
- [Release notes](https://github.com/eslint/rewrite/releases)
- [Changelog](https://github.com/eslint/rewrite/blob/main/packages/plugin-kit/CHANGELOG.md)
- [Commits](https://github.com/eslint/rewrite/commits/plugin-kit-v0.3.3/packages/plugin-kit)

---
updated-dependencies:
- dependency-name: "@eslint/plugin-kit"
  dependency-version: 0.3.3
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bumps [form-data](https://github.com/form-data/form-data) from 4.0.2 to 4.0.4.
- [Release notes](https://github.com/form-data/form-data/releases)
- [Changelog](https://github.com/form-data/form-data/blob/master/CHANGELOG.md)
- [Commits](form-data/form-data@v4.0.2...v4.0.4)

---
updated-dependencies:
- dependency-name: form-data
  dependency-version: 4.0.4
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

We use ansis elsewhere in the Netlify stack, so we should probably do the same
here. ansis is also smaller and faster.

Co-authored-by: Mateusz Bocian <mrstork@users.noreply.github.com>

This changeset makes a light breaking change to the way local extension build plugins work. This fixes an issue where functions injected using the `functions.generate` API silently fail to include `node_modules` required for the function to work.

Currently, during `netlify build` and `netlify dev`, build will automatically build your extension and include any build plugins produced by that extension in the build process if you specify this configuration in your `netlify.toml` (documented [here](https://developers.netlify.com/sdk/build-event-handlers/debug-and-test/)):

```toml
# netlify.toml

[[integrations]]
name = "my-local-extension"

[[integrations.dev]]
path = "../some-local-path-to-integration"
force_run_in_build = true
```

To make it short(ish): This process makes a lot of assumptions about the default file structure of a Netlify Extension. It also installs dev-mode extension build plugins using a different code path than for production extension build plugins: In production, we do an `npm install` against a tarball; in development, we point build at a directory and no installation is performed. (This is the crux of the `functions.generate` problem: the directory we point build at is a temporary build directory and does not contain `node_modules`.) We use dev-mode extensions in SDK/build integration tests, so this problem breaks our existing tests and generally makes it difficult to trust that SDK tests will catch real-world, user-facing build plugin problems.

With these changes, build no longer automatically builds extensions. Instead, it assumes that you've already built your extension, and will now install extension build plugins from a local tarball. This makes dev mode behave very similarly to production mode builds.

You can now point build at a tarball:

```toml
# netlify.toml

[[integrations]]
name = "my-local-extension"

[[integrations.dev]]
path = "../some-local-path-to-integration/buildhooks.tgz"
# Note: force_run_in_build is no longer required
```
To make the transition on this change easier, you can instead point build at a directory, and the historical default extension build hooks tarball path will be inferred:

```toml
# netlify.toml

[[integrations]]
name = "my-local-extension"

[[integrations.dev]]
# Expands to "../some-local-path-to-integration/.ntli/site/static/packages/buildhooks.tgz"
path = "../some-local-path-to-integration"
```

There's part of me that thinks, "This behaves slightly differently than local build plugins, and that asymmetry sucks." But: Local build plugins are meant to work when developed in the same tree as the site they're modifying. For better or for worse, developing extensions in the same tree as a site is not supported. So, this asymmetry actually feels appropriate to me.

---

Footnote: This corner of the code had a lot of dead code, code that was untyped, code that was added to avoid updating test fixtures, code that was unnecessarily complex, etc. etc. I did some refactoring along the way to make this functionality easier to implement, and those refactors are included in this PR. Most of the substantial stuff is concentrated in 5-6 files and is fairly well split out into separate commits. To weed out refactors from feature work, though, you might find this easier to review commit by commit.