Add a request option for custom headers

[dlarocque]

Allow users to pass custom request headers through request options.

Questions:

• If a user passes a customHeaders object that isn't a Header (e.g. customHeaders: { headerName: 'headerValue'}, rather than customHeaders: new Headers({ headerName: 'headerValue' })), should we a) raise a TypeError: url.requestOptions.customHeaders.entries is not a function, or b) Ignore the custom headers?
• The original CL adds checks for newlines in apiClient and customHeaders fields. Should these checks be added to this PR, or a separate one?

[hsubox76]

• If a user passes a customHeaders object that isn't a Header (e.g. customHeaders: { headerName: 'headerValue'}, rather than customHeaders: new Headers({ headerName: 'headerValue' })), should we a) raise a TypeError: url.requestOptions.customHeaders.entries is not a function, or b) Ignore the custom headers?

A Typescript user will get a compile-time error right away, but we likely have a lot of non-Typescript users so I think it's worth throwing an error. Probably we should do a more informative one. I'd probably do an instanceof Headers check and then throw a GoogleGenerativeAIError saying customHeaders must be an instance of Headers. We can also allow customHeaders?: Headers | Record<string, string> and if it's not instanceof Headers then try to convert it with new Headers(customHeaders), wrapped in a try/catch where the catch rethrows the message wrapped in GoogleGenerativeAIError and additional text "unable to convert customHeaders value to Headers", if it throws. I'm not sure what kind of errors a failed new Headers(init) throws, if any.

[hsubox76]

Looks good! Just one more comment, and add a changeset.

[hsubox76]

Looks good, just add a changeset.