Node support strategy

[Nevon]

This came up with #250.

Until now, we've basically had a general idea about supporting Node version 8+, which in reality meant whatever version of 8 that Travis is running. Coupled with this, we know that we eventually want to drop support for 8, so that we can drop our last dependency and use native BigInt.

I would suggest that we follow the same support pattern that NodeJS itself uses (https://github.com/nodejs/Release#release-schedule), with us supporting any version of Node from active LTS until current release. This would mean that we would have dropped support for 8.X in Jan 2018, support 10.X until April 2020, and should support 11.X since 2018-10-23 and 12.X from 2019-04-23.

Alternatively, we could adopt the same schedule as node, and also support LTSs that are in maintenance mode. This would essentially extend the lifetime of another year, which means we would drop 8.X support in Jan 1st 2020.

See the "current" and "active" sections of this:

If this sounds reasonable, then there are some things we should do:

• Document support strategy
• Update Travis config to test on all supported versions
• Establish a timeline for dropping 0.8 support (this would imply a major version change)

[KBInmarsat]

My 2c, we only recently updated to node8, we are very conservative with updates as we don't rollout new versions unless there is a bug/new feature. In the past we've not used certain libraries because of this so there is something to be said for being more conservative.

[Nevon]

For now, our version support strategy is quite simple. We will support all LTSs through both active and maintenance stages. This means that Node 8 will be supported at least through 2019.