Add support for secrets in gcfv2 endpoints

[taeold]

We now read secretEnvironmentVariables property from the endpoint manifest and include the property when creating/updating v1 and v2 functions.

Side note - if secretEnvVar in the manifest is missing secret property (i.e. doesn't specify the secret resource name), we'll assume that resource name matches the key property. This will be the case for all CF3 functions.

[TheIronDev]

Nit:

const supportedPlatforms = new Set(["gcfv1", "gcfv2"]);
const unsupported = endpoints.filter((e) => !supportedPlatforms.has(e.platform));

Nit x2: I don't know how often this is called, but maybe it makes more sense to have this defined as a const up top?

[taeold]

You and @inlined should have a talk! @inlined does not like Sets, especially in our code where N is almost always < 50 where using Set (which has every so slightly different API from arrays) doesn't give us much!

[TheIronDev]

Team convention is king. :)

That said, my thoughts are its less about efficiency and more about intention/code clarity.

Set limits the purpose of the variable/code to just checking for existence.

Array leaves the implementation open ended. Maybe the array going to be used with has, reduce, or map. Someone else won't know unless they read through the code to find how/why the array is being used.