[JS] Reorganize imports and exports to be more friendly to ESM tree-shaking

[asfimport]

Presently most of our public classes can't be easily tree-shaken by library consumers. This is a problem for libraries that only need to use parts of Arrow.

For example, the vis.gl projects have an integration test that imports three of our simpler classes and tests the resulting bundle size:

import {Schema, Field, Float32} from 'apache-arrow';

// | Bundle Size | Compressed 
// | 202KB (207112) KB | 45KB (46618) KB

We can help solve this with the following changes:

• Add "sideEffects": false to our ESM package.json

• Reorganize our imports to only include what's needed

• Eliminate or move some static/member methods to standalone exported functions

• Wrap the utf8 util's node Buffer detection in eval so Webpack doesn't compile in its own Buffer shim

• Removing flatbuffers namespaces from generated TS because these defeat Webpack's tree-shaking ability

  Candidate functions for removal/moving to standalone functions:

• Schema.new, Schema.from, Schema.prototype.compareTo

• Field.prototype.compareTo

• Type.prototype.compareTo

• Table.new, Table.from

• Column.new

• Vector.new, Vector.from

• RecordBatchReader.from

  After applying a few of the above changes to the Schema and flatbuffers files, I was able to reduce the vis.gl's import size 90%:

  // Bundle Size | Compressed
  // 24KB (24942) KB | 6KB (6154) KB

Reporter: Paul Taylor / @trxcllnt
Assignee: Paul Taylor / @trxcllnt

PRs and other links:

• GitHub Pull Request #8418

_{Note: This issue was originally created as ARROW-10255. Please see the migration documentation for further details.}

[asfimport]

Brian Hulette / @TheNeuralBit:
[~paul.e.taylor] should we have a deprecation cycle for the removed/moved functions to avoid suddenly breaking any users?

[asfimport]

Paul Taylor / @trxcllnt:
@TheNeuralBit I vote no on the current PR for 4 reasons:

1. Arrow releases have moved to releases major-version-revs only, so npm won't upgrade libs/people by default
2. The very minor changes we had to make to our own tests makes me think this shouldn't be a huge pain to upgrade for users (not to mention Field and Schema aren't the most common APIs to interact with directly)
3. These changes are needed by vis.gl to import ArrowJS in loaders.gl. Currently they're reimplementing the bits of Schema/Field/DataType they need because importing ours adds ~250k (~24k minified) to their bundle, which is over their size budget.
4. Adding deprecation warnings will add to the size of the lib, and likely in ways that can't be tree-shaken. In Python size on-disk isn't an issue, so people add deprecation warnings all the time, but without extensive tooling support it's difficult to do/guide users how to do in JS.

[asfimport]

Krisztian Szucs / @kszucs:
Issue resolved by pull request 8418
#8418