Provide TS types for non-standard `fetch` request init `cf` object

[allanvobraun]

The cloudflare typings for the fetch seems to be different in cloudflare:
Example:

 let response = await fetch(request, {
      cf: {
        // Always cache this fetch regardless of content type
        // for a max of 5 seconds before revalidating the resource
        cacheTtl: 5,
        cacheEverything: true,
        //Enterprise only feature, see Cache API for other plans
        cacheKey: someCustomKey,
      },
    });```
In deno the following error occurs:

No overload matches this call.
Overload 1 of 2, '(input: string | URL | Request, init?: RequestInit | undefined): Promise', gave the following error.
Argument of type '{ cf: RequestInitCfProperties; }' is not assignable to parameter of type 'RequestInit'.
Object literal may only specify known properties, and 'cf' does not exist in type 'RequestInit'. Overload 2 of 2, '(input: string | URL | Request, init?: (RequestInit & { client: HttpClient; }) | undefined): Promise', gave the following error.
Argument of type '{ cf: RequestInitCfProperties; }' is not assignable to parameter of type 'RequestInit & { client: HttpClient; }'.
Object literal may only specify known properties, and 'cf' does not exist in type 'RequestInit & { client: HttpClient; }'.deno-ts(2769)```

[johnspurlock-skymethod]

Yep, since Cloudflare deviates from the web-standard global fetch signature (provided by Deno tooling), you'll have to escape TS type constraints for the options object. e.g. as any

However, I'll keep this issue open, since Denoflare should at least provide typings for that cf property, the way it does for the incoming cf property inside the worker handlers, so folks can get docs/typings for those subproperties if desired.