Measure action registration in KeyBindingServicePerformanceTest

[vogella]

CommandsPerformanceTest covers binding resolution, the keystroke to command direction inside JFace. Nothing covered the workbench side, where a part registers its actions with the key binding service while it is being created. AbstractTextEditor does that dozens of times per editor, so it sits directly on the editor open path, and it had no measurement at all.

Register and unregister are timed separately, and the action count is a parameter so the growth of the cost with the number of actions is visible rather than only its value at one arbitrary size.

KeyBindingService register 25 actions            n=200  min=0.04  p50=0.05  p90=0.08 (ms)
KeyBindingService register 50 actions            n=200  min=0.08  p50=0.10  p90=0.13 (ms)
KeyBindingService register 100 actions           n=200  min=0.16  p50=0.20  p90=0.23 (ms)
KeyBindingService register 200 actions           n=200  min=0.29  p50=0.39  p90=1.22 (ms)

The first thing this settles is the size of the prize. Registering 200 actions costs about 0.3ms in total, against an editor open of roughly 22ms, so nothing on this path is worth optimizing for its own sake.

It also puts a number on #4243, which replaces the O(n^2) scan in registerAction with a map lookup. Re-running this test with that change applied gives 0.04 / 0.05 / 0.10 / 0.26 ms at the four sizes against 0.04 / 0.08 / 0.09 / 0.28 without it, so the difference is within noise. That is the expected result: registration cost is dominated by activateHandler and the context invalidation it triggers, not by the scan. Better to have the measurement than the guess.

Independent of #4244, though it pairs naturally with it.

[github-actions]

Test Results

   858 files  ±0     858 suites  ±0   55m 20s ⏱️ - 12m 7s
 8 160 tests ±0   7 917 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 382 runs  ±0  19 728 ✅ ±0  654 💤 ±0  0 ❌ ±0 

Results for commit 300c501. ± Comparison against base commit 420efae.

♻️ This comment has been updated with latest results.