Option to use bigint primitive or BigInt wrapper instead of long.js

[altro3]

ECMAScript 2020 is now supported by all modern javascript engines. It would be cool not to use third-party libraries (Long.js), but to use internal browser capabilities for large numbers.

[stephenh]

@altro3 FWIW reopening this b/c I think it's a great idea; long.js doesn't support ESM and that's been annoying a few times.

[altro3]

@stephenh Hi! Yeah, it's good idea, but problem in library protobuf.js. I closed this issue, because protobuf.js as I undersatnd doesn't support bigint. See PR: protobufjs/protobuf.js#1557.

And you can see theirs answer:

Hi @mjgp2,

Thank you for this PR. We probably cannot include it in v7.0.0 (that is coming soon) but we'll think if we can drop long in the next semver major. At least this would be a major pain for us at Google to convert all the client libraries (which reexport types from protobuf.js), and I can only imagine how disruptive it can be for others. Also, if you see how the long support is implemented, there's a configuration option that enables or disables long. It maybe makes sense to think if we can make this less breaking by doing it in steps:

(1) start accepting BigInt where we currently accept long when serializing;
(2) make it configurable to be able to choose if we dump long or BigInt.

Also, dropping support for Node.js v4-6-8 is a big decision.

Of course, Cc: @dcodeIO on this.

I promise we'll get back to reviewing this PR when we're done with releasing v7.0.0 :)

But, of course, your library can replace Long to bigint by itself :-). If you can do it - it would be perfect :-)