feat: compiler benchmarks and gh action

[MrArnoldPalmer]

Adds a private package @jsii/benchmarks which includes a basic command line application for running jsii benchmarks.

Adds a custom benchmark runner leveraging the NodeJS perf_hooks module to time function calls across multiple iterations and return averaged results.

Adds github action workflows to run benchmarks on PRs and compare performance to the target branch. This action will fail when a test suite is slower by 200%, but this threshold can be configured.

Adds to the gh-pages action workflow to run benchmarks and append new results to a file that is displayed as a graph on our docs site at the /dev/bench url. This will show benchmark suite results over time and allow us to track overall change in compiler performance across multiple commits.

Example of benchmark results comment MrArnoldPalmer#417 (comment)
Example of benchmark results graph (but only 1 result cause just testing) https://mrarnoldpalmer.github.io/jsii/dev/bench/

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[MrArnoldPalmer]

Added DNM as benchmark.js doesn't really support what we want to do. Writing a basic custom runner that generates output that the action we use supports so we should still get the graphs on gh-pages and the comments for regression exceeding defined threshold.

[MrArnoldPalmer]

Changed strategy a bit since last review @RomainMuller @yuth

1. Removed benchmark.js for a really simple custom runner using the node perf_hooks module. Benchmark.js wasn't cutting it for us as it isn't really built around running tests that may require cleanup in between. There are no apis for cleaning up the target directory in between runs and therefore after the first run, JSII essentially no-ops, skewing the results.

2. Added a fixtures directory that has a snapshot of the aws-cdk-lib project ready to build (meaning you can run npm install and then JSII is able to compile it). This greatly reduces the time of running the benchmark as cloning the repo, building all the submodules, running ubergen, removing build artifacts, THEN running JSII, is a lot of setup. I did include the script I used to snapshot it so we can rerun that or add new versions of cdk, or other modules, though some of it is aws-cdk-lib specific).

I also investigated including profiles and graphing difference in cpu/memory usage as well but it's non-trivial and we can add it after the fact if that data is interesting to us.

[yuth]

LGTM!

[RomainMuller]

A bunch of cosmetic feedback, feel free to ship it after having reviewed that...

[RomainMuller]

npm ci? Isn't CDK using yarn?

[MrArnoldPalmer]

it is, but the snapshot we are taking is outside of the yarn workspace and we run npm install. we can alternatively do yarn install and generate a yarn.lock but this assumes less about the environment?

[mergify]

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

[mergify]

Merging (with squash)...