feat(build): add utils.deploy.env.add build plugin API

[ndhoule]

feat(build): add utils.deploy.env.add build plugin API

This changeset adds a new utility to build plugins:
utils.deploy.env.add(). This utility function allows build plugins to
register environment variables at build time that will be injected into
a specific deploy.

Userland build plugins cannot see or manipulate the deploy environment
variables registered by core or other userland plugins.

Deploy-specific environment variables are collected by the build
supervisor process and processed by the deploy step, which sends them to
Buildbot for processing. They are also returned by the programmatic dev
interface; we'll use these returned variables in the CLI, where we'll
e.g. set them on functions.

While I was in here I also converted a few files to TypeScript/generally
did my best to improve the types along the way.

[github-actions]

This pull request adds or modifies JavaScript (.js, .cjs, .mjs) files.
Consider converting them to TypeScript.

[VitaliyR]

LGTM, minor comment

[jaredm563]

last thing i can think of @ndhoule , maybe there is still WIP, i havent been following very much so might not apply.

Here's a little gap I found w the transport logic:

Background:

1. models.DeployEnvironmentVariable in the open-api package has scopes as a required field

2. The buildbot test at deploy_server_test.go:239-254 tests scopes e-2-e

3. the deploy server deserializes and forwards them to SetEnvironment() on the builder.

The gap: in util.ts we calculate normalizedScopes but it stores only { key, value, isSecret } (no scope)

That means buildbot receives env vars without scopes,which is a lil confusing since the Open API model says it's required which leads me to think that vars will get broader exposure than you are intending

Side note; (in the open api enum)
buildbot uses post-processing (kebab)
build uses post_processing (snake)
Can this little difference cause a scope mismatch?

[ndhoule]

@jaredm563 Totally correct, just an oversight. Addressed in 97a4d85

[jaredm563]

Whew! Structure looks great so far! Putting some last thoughts regarding transport flow (in a comment because im being a bum >:)), then I'll let @eduardoboucas give another set of eyes since he's much more familiar than me with this architecture

1. [Maybe bug] We should double check if let normalizedScopes = new Set(...scopes) behavior is correct. I'm still a little suspicious the Set() primitive will only take in one iterable argument, but we are using spread operator. Tests are passing so maybe this is intended behavior?

smol code example

new Set(...['builds', 'functions'])
// equivalent to: new Set('builds', 'functions')
// 'functions' is ignored → Set { 'b', 'u', 'i', 'l', 'd', 's' }

2. [Bug] Seems like a little JSON mismatch here, what do you think?

in buildbot_client: environment: { key: string; value: string; isSecret: boolean }[]

But the Go model always expect isSecret

IsSecret bool `json:"is_secret,omitempty"`

So, "isSecret" key -> IsSecret is always false.

3. [TS Nits] Since we are converting to TS (Thank you for doing this btw @ndhoule ) there are some intermediete types we could add scopes

BuildRequest.environment line 54 needs scopes
deploySiteWithBuildbotClient param line 117 needs scope
CoreStepFunctionArgs.deployEnvVars types.ts:47 needs scopes

[ndhoule]

@jaredm563 Addressed all those comments. Thanks for the in-depth review!