Documentation updates for v8

[mfedderly]

Based on how things are going with v7, I'd like to make several policy changes when we finally make the next major release. These changes should hopefully let us ship new code without being quite so restricted by compatibility demands.

Specifically:

• turf.min.js should have a rolling target of some reasonable level of browser support
• All other published code is declared as targeting esnext, and therefore requires transpilation and polyfilling by consumers
• Even though we're targeting esnext, we won't break nodejs compatibility without a major and therefore shouldn't be hitting the most bleeding edge syntax anyhow
• We officially state that we do not promise more than 6 digits of precision (~10cm error), which gives us better guidance when tuning our own implementations

This is intended as a starting point for all of the wording, happy to receive feedback and make this better.

cc @bratter

[bratter]

Couple of thoughts on the precision topic. Don't feel well equipped to comment on the versioning question given my use cases, but seems reasonable.

[bratter]

I would always use "precision" rather than accuracy given that the two concepts are subtly different.

[bratter]

Consider "we use JavaScript's built in types for performance reasons."

I also wonder if we could add a suggestion along the lines of: "Where operations don't depend directly on lng/lat coordinates, it is often possible to increase the effective precision on small shapes by first transforming to a zoomed in projection, running an operation, then re-projecting to lng/lat." i.e., help people understand that there are alternatives. Just a thought.

[mfedderly]

We should also make it clear that we may bring in libraries that also need to be handled. Interestingly the first candidate here would be clipper2-ts, which can't really safely be polyfilled with the BigInt syntax.