Upgrade to v4.0.0-rc2 (take two)

[nrabinowitz]

Supersedes #136

@isaacbrodsky and I agreed that I should take on the subsequent work on his PR, and with separate forks the easiest option was to open a new PR with his commits + my commits. For the most part, my commits cover my own code review comments on the previous PR.

Summary of my additional changes:

• Updates to error handling, including adding the core library code to the error and using a similar code-based approach for binding-level errors
• Renaming various variables and internal functions to better align with v4
• Using a C helper to support reading int64 values as JS 64-bit floats (confirmed this appears precise up to MAX_SAFE_INTEGER)
• Test updates, particularly around testing the new errors

[coveralls]

Pull Request Test Coverage Report for Build 2631277174

• 318 of 318 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 2543820363:	0.0%
Covered Lines:	510
Relevant Lines:	510

---

💛 - Coveralls

[nrabinowitz]

Note that the renaming of distance here should probably wait for uber/h3#622 to be resolved

[nrabinowitz]

Note that the renaming of distance here should probably wait for uber/h3#622 to be resolved

Actually, I walked this back in the JS code - we can update with the next release candidate.

[isaacbrodsky]

Seems like the function name should indicate a cast is happening. That kind of precision losing cast can be an unexpected operation.

[nrabinowitz]

I guess I can update to readInt64AsDoubleFromPointer - a little wordy, but accurate

[nrabinowitz]

It's worth noting though that losing precision will be very rare - the total count of res 15 tiles is still lower than MAX_SAFE_INTEGER. I can't think of a scenario in our current usage where we would deal with an int64 value that's bigger than this.