Which problem is this pull request solving?

Currently, the client is loading the context from an environment variable called NETLIFY_BLOBS_CONTEXT, so both serverless functions and edge functions need to set the updated context on each request, by setting process.env.NETLIFY_BLOBS_CONTEXT in Node.js and by calling Deno.env.set() in Deno.

I wanted to see if there was any performance penalty in calling Deno.env.set() versus just setting a global variable, so I ran this benchmark and ran it a few times:

Deno.bench("Environment variable", { group: "timing", baseline: true }, () => {
 for (let i = 0; i < 50_000; i++) {
 Deno.env.set("SOME_VAR", `foo${i}`);
 }
});
Deno.bench("Global variable", { group: "timing" }, () => {
 for (let i = 0; i < 50_000; i++) {
 // @ts-expect-error No types for global variable
 globalThis.someVar = `foo${i}`;
 }
});

These are the results I'm seeing:

cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
runtime: deno 1.35.1 (x86_64-apple-darwin)
file:///Users/eduardoboucas/Sites/tests/deno-bench/index.ts
benchmark time (avg) (min ... max) p75 p99 p995
------------------------------------------------------------ -----------------------------
Environment variable 43.42 ms/iter (39.8 ms ... 52.1 ms) 43.95 ms 52.1 ms 52.1 ms
Global variable 2 ms/iter (1.68 ms ... 3.34 ms) 2.13 ms 3 ms 3.09 ms
summary
 Environment variable
 21.72x slower than Global variable

I'm consistently seeing the environment variable set being ~20x slower than the global variable equivalent. In an environment where every millisecond counts, I think we should try to optimise this as best as we can.

So in this PR I'm making it possible for the client to read the context from a netlifyBlobsContext environment variable before trying to read it from an environment variable.