Allow all sst components to optionally override the DEFAULT_ACCOUNT_ID

[DJDANNY123]

Closes #6769

Context

The Cloudflare provider is a bit weird in the way it expects you to specify the accountId on the resource, but API token on the provider.
SST made the choice to default the accountId to an environment variable for all the resources it provisions, as it is annoying to specify this for every resource, however this makes it difficult for multi-account deployments.
This is compounded as some of the resources can't be accessed/overridden by the transforms property (e.g. the custom domain of a worker).

This Change

This change simply extends each cloudflare SST component with an optional accountId, which will be used if specified for provisioning/querying all resources within this component.

[vimtor]

thanks for your contribution @DJDANNY123

this week we're adding a lot of Cloudflare components, let's wait until we finish so you can update your PR

in the meantime, i wonder if this is the ideal setup. maybe we should let you define multiple providers, each using a different account. not sure how that would look, though

[vimtor]

just realized that what we should do is to find a way to do this:

const provider = new cloudflare.Provider("OtherAccount", {
  apiToken: "",
})

new sst.cloudflare.Bucket("Bucket", {}, { provider });

this would match the aws behaviour

[DJDANNY123]

I don't understand your code example, I believe we can already do this with the existing implementation.
The issue is in specifying the accountId which is a required argument for all plain cloudflare components, and we can't specify the accountId in the provider.

Ideally the cloudflare provider would accept an accountId, and use this for relevant resources but this would probably be a fairly major change in the cloudflare Pulumi resource provider.

I think given the current state of the downstream provider, we should mimic how the downstream provider works (but still keep the existing default account behaviour for ease of people who don't need to do multi-account deployments)

// define a provider with another api token for a different account
const provider = new cloudflare.Provider("AnotherProvider", { apiToken: "" });

// deploy a plain cloudflare resource in the other account
const plainCfResource = new cloudflare.R2Bucket(
  "",
  { name: "MyBucket", accountId: "ANOTHER_ACCOUNT_ID" },
  { provider },
);

// deploy a sst component in another account in the same way
const sstResource = new sst.cloudflare.Worker(
  "MyWorker",
  { handler: "index.ts", accountId: "ANOTHER_ACCOUNT_ID" },
  { provider },
);