protocols/horizon/effects: Add UnmarshalJSON to SequenceBumped.

[abuiles]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

Add UnmarshalJSON to SequenceBumped, this method supports new_seq as a string or a int64 in the JSON payload. This will allow us to cut a new release for the horizon client which won't break once we change the data type on the JSON payload.

Why

Using Int64 in JSON payloads produces inconsistent results in JS (see #1363).

We are in the process of updating all the int64 JSON fields to be of type string. The idea with this change is to extend the Unmarshal function to take either int64 or string, that way we can release a version of the horizon client which won't break once the payload changes in the API.

See #1609

Known limitations

[TODO or N/A]

[ire-and-curses]

LGTM, just small comments

[tamirms]

you can use json.Number instead of an interface map:

https://play.golang.org/p/epDKjGKeg7d

[abuiles]

@ire-and-curses I split the test so it's clear what is being tested.

@tamirms I updated the code to use json.Number - thanks!