Add binary size testing

[sffc]

In each component, we should have a set of demo files that illustrate common use patterns. We should then compile those demo files with optimizations for code size (-s), and have a test that reports their sizes and complains if they grow.

I suggest building the demo files to WebAssembly and checking the size of the output .wasm file, because:

1. WebAssembly is not platform-dependent
2. WebAssembly has good tooling to inspect what causes size regressions to occur
3. We have WebAssembly in mind as a possible target in the future

[zbraniecki]

I think cargo /examples may be a good vehicle for such little demo apps. Also, it's related to #107 and maybe we could visualize it via #117.

[sffc]

Sounds good. I can't seem to find the official documentation for the examples/ directory, but I found it mentioned in a few places:

https://www.google.com/books/edition/_/kOiZDwAAQBAJ?hl=en&gbpv=1&pg=PA66&dq=cargo+examples+directory

[eyeplum]

Sounds good. I can't seem to find the official documentation for the examples/ directory

This and this might explain examples/ a bit more :)

[sffc]

With #365 merged, this issue is unblocked. We can test how the size of the *.wasm files changes across PRs.

[gnrunge]

Questions of a newcomer:

• Do the demo files mentioned above exist? What are the common use pattern?
• How to build the compiled demo files?
• Will GHA be a suitable platform for this CI task? GHA is stateless, isn't it?

[sffc]

The demo files are found in the examples/ directories in each component. You can build them to WASM by running cargo make wasm, and from there you can measure their file size.

I imagine the file size should be recorded in a manner similar to how we record performance data (cc @echeran).

[echeran]

Yes, I expect binary size testing would be similar to performance testing. Ideally, the manifestation of the information would be a dashboard that allows us to notice changes over time. The reason is the same for performance testing -- it is easier to help us determine whether a change in metric value is reasonable through comparison to previous values than it would be assessing the absolute number directly.

For dashboards, we have a high-level overview of how the dashboard action works and inline source comments. I think that we could reuse the dashboard, but instead of providing it a performance metric number, we provide it a different number (binary size), and inherit the benefits of the dashboard 'infrastructure' provided by the GH Action.

Specifically, this would be providing our own value to the tool parameter of the benchmark dashboard GH Action to represent binary size testing. Seeing that the tool parameter is required and must be provided from a short list of options that represent supported performance testing tools, we would need either:

1. The benchmark action repo to genercize its notion of a benchmark tool
2. Fork the benchmark action repo and modify it to have support for binary size numbers. It might be similar to how people have created working support for benchmarkdotnet via their fork, but perhaps with less logic required. At first glance, it seems like the core of the work is mimic the JSON format consumed directly by the benchmark action (and thereby skip the benchmark output -> JSON conversion) followed by enabling a new corresponding option for the tool parameter.

[gnrunge]

Draft PR: #859