Add support for auth token in header

[zachalam]

Some paid node providers require authentication to prevent abuse / DDoS attacks. A way of doing this is by proving an auth GET parameter in the server url when a “stellarsdk.Server” object is created. For security purposes, node providers may remove this auth token by purging it from the responses. And since the sdk uses some values in the response for future requests, the sdk no longer has context of the auth token. As a result, some calls to library methods like next() and prev() fail.

This PR adds support for a new custom header when a new stellar server object is created, namely X-Auth-Token. Adding support for this header allows us to authenticate against a node & have the sdk keep track of the authentication value.

[Shaptic]

Two thoughts:

1. I have no qualms with the feature, but some cursory research gives low confidence in X-Auth-Token as a meaningful header value. It's unspecified by IANA and would be unused by the public Horizon servers.
2. I don't want to set a precedent for this kind of change every time a custom header is necessary, and instead would rather give a general way to allow custom headers (without finagling the HorizonAxiosClient directly).

How do you feel about a change that allows something like opts.extraHeaders: Array<{string: string}> (or just an object) that merges with customHeaders, instead?

[JakeUrban]

@Shaptic I agree that an opts.extraHeaders or something similar is the ideal, but my concern is that we'll have two headers outside this object, opts.appName and opts.appVersion, and then the remaining headers in opts.extraHeaders.

Ideally, we'd migrate both of the existing headers into a single customHeaders object.

For now, can we move forward adding X-Auth-Token? This is the header that blockdaemon uses.