feat: added benchmarks for CESQL

[Cali0707]

Fixes #927

This PR adds benchmarks to run on every TCK test case that we have, as that seemed like the easiest way of getting a good set of test cases. For each scenario, this benchmarks:

1. The parsing
2. The evaluation

Since all these cases are already being tested for correctness, this does not bother checking if the results are correct

[Cali0707]

cc @duglin @pierDipi

[duglin]

LGTM but I've never really used the go benchmark stuff before... so a potentially silly question, I assume this will print stats about the testcases (e.g. timing, etc...), but is there a mechanism in all of this that compares the values with the state of the code before whatever PR is being tested? How will people know if a PR impacts performance dramatically w/o the historical info?

[Cali0707]

@duglin we tried to think this through in Knative and didn't come to a great conclusion. The main challenge with historical info is that it is really dependent on the machine the code is running on. We found that the github action runners were too noisy for good benchmarking.

So, our solution was to just run the benchmarks once on the main branch and then once on whatever branch had the changes when we were making a change that might impact performance, and then there is some tooling to compare those two results. If you can think of a better workflow I would be very interested in trying that!

[duglin]

Nope - that seems reasonable. Would be really cool if the PR testing infra could do that on each PR and flag it when things look bad. But that's just a dream :-)

[pierDipi]

LGTM

[pierDipi]

cc @cloudevents/sdk-go-maintainers

[Cali0707]

cc @embano1

[duglin]

rebase needed