Allow headers type in DefaultContext to be Record or HttpHeaders

[vz-tl]

Fixes #2386

Hi @PowerKiKi , in contrast to my initial assumption (see above issue), the fix for restoring the previous flexibility of using Record<string,string> as headers type in operation context required some additional changes.

The reason is, that headers can be applied in 2 different locations, which are HttpLink options and operation context.

In versions before v12, HttpLink options always required type HttpHeaders (hence this should still remain), but headers in the operation context could also be defined as Record<string,string> (which btw. is in accordance to @apollo/client as well as Angular HttpClient specs).

So, in order to restore the pre-v12 flexibility of using a header object, it now was required to add some more checks to ensure the headers finally to be in the expected HttpHeaders format. And here I noticed, that before v12, assigning Record-type headers to the operation context just worked by coincidence, as finally the object-type headers became converted to HttpHeaders by createHeadersWithClientAwareness() method. This worked flawlessly for the basic HttpLink, but with HttpBatchLink it apparently could lead to errors when using objects.

However, as previously it was allowed to use object-headers and as even apollo-angular already does some internal conversion from object to HttpHeaders, I think it's still important to allow both header types in operation context by taking care for proper conversion, which also will fix the error when using object-headers with HttpBatchLink.

Please have a look at the changes and let me know your thoughts.

[vz-tl]

@PowerKiKi , here was already a check/conversion to HttpHeaders missing, which led to a stacktrace in case of using object-type headers. Adding convertToHttpHeaders(contextHeaders) will fix that.