Benchmarks completely redone

[voidpumpkin]

Description

A lot has been done so here is a compiled list to get you up to speed:

• redone benchmark action completely, it now
  • pulls from js-framework-benchmark master
  • uses new crates that are essentially copies from js-framework-benchmark, being tools/benchmark-struct tools/benchmark-hooks
  • displays results using github-action-benchmark (see pictures)
  • stores every commit results in gh-pages branch and we can serve that using github pages
• new crate tools/process-benchmark-results introduced, to transform data to be ready for github-action-benchmark
• use caching all around so now benchmarks take ~6 minutes

Preview:

gh-pages page

Comment on the commit with the results:

Alert comment when 150% threshold is reached:

Fixes #1453
Fixes #858
Touches #5 I would just need to add docs about these benchmarks somehow

Checklist

• I have run cargo make pr-flow
• I have reviewed my own code
• I have added tests

[voidpumpkin]

I would assume that there is no comment on my commit atm, because master latest commit has not been benchmarked and thus my commit has nothing to be compared against.

[ranile]

Where does it store the previous results needed to build the new site?

[voidpumpkin]

Where does it store the previous results needed to build the new site?

In gh-pages branch

[Madoshakalaka]

I wonder whether the accumulated graph makes sense in the long term, since we can't control the hardware in github actions.

[Madoshakalaka]

Suggested change

	Except the fixes required to tun using unreleased yew version.
	Except the fixes required to run using unreleased yew version.

[ranile]

I have nothing against this. If any issues pop up, those can be resolved later.

I do share the runner hardware concerns mentioned in #2352.

A (potentially crazy) idea I had was to save the benchmark results in Firestore. Not sure how applicable that is though