Release custom headers for requests

[nicksay]

This change removes the "experimental" gate to allow the client
to specify custom headers to send with requests.

The headers may be set globally using the request-headers config:

spf.init({
  'request-headers': {
    'X-Custom-Header-One': 'Custom Value One',
    'X-Custom-Header-Two': 'Custom Value Two'
  }
})

Or, they may be set on a per-request basis for API calls using
the headers option:

spf.navigate(url, {
  headers: {
    'X-Custom-Header-One': 'Custom Value One',
    'X-Custom-Header-Two': 'Custom Value Two'
  }
})

Closes #390

[rviscomi]

LGTM. Update the docs as well? (doc/api.md)

[nicksay]

In the past, we've updated doc/api.md once per release, but I'm working on this process now (e.g. #408 and #409).

One concern with updating doc/api.md along with src/api.js is the following in doc/api.md:

The following API reference is for SPF 23 (v2.3.2).

It might be confusing for there to be unreleased changes in the file.

The other concern I have is pushing the website. Since the website files are generated from the doc folder, any unreleased changes might accidentally get pushed to the website.

Thoughts?

[rviscomi]

Ah I see your point. So you only update the docs after the release? How do you keep track of everything that needs to be updated?

[nicksay]

The docs/api.md file is auto-generated from src/api.js, so that is taken care of automatically by using the version of src/api.js that is tagged for that release. (See bin/gendocs.sh.)

For the textual documentation, we don't have a great process right now. So far, we have only ever written docs for already released changes, so it hasn't come up. 😒

[rviscomi]

Ok sgtm thanks for explaining