Bundle package

[fisker]

Fixes #45

This script should be good enough to bundle the package.

Should we do this in core? Since we have more esbuild plugins there, this repo don't need to worry about the bundle step.

[fabiospampinato]

I can't test this now, but as a brain dump:

1. We should go over each dynamic import to check if they still work.
2. We should explicitly test that all the various ways of executing prettier still work (serial, serial+cache, parallel, parallel+cache). Probably worth adding some automated tests for these anyway.
3. I think we need to experiment a bit to figure out which actual files we need to generate, because:
   1. The file for the bin itself should be fairly small, so that we can show some things like the help page very quickly.
   2. There should be a big file containing prettier itself.
   3. Presumably lazy-loaded dependencies should be code split, as we don't actually need to load all of them all the time.
   4. Presumably all the optional lazy parsers and plugins for prettier should be code split for the same reason.
   5. We should probably write this while thinking about, if not fully wiring, code caching, which may speed up startup significantly and it may change the assumptions made above regarding code splitting. And I think we may need another file to load the bin file from to enable code caching, and another file to load prettier from to enable code caching for the workers.

Should we do this in core? Since we have more esbuild plugins there, this repo don't need to worry about the bundle step.

Keeping the two separate seems easier to manage to me, especially at the present where this code lives in its own repo. I'm not sure we need particular esbuild plugins? 🤔