Investigate performance of `menubar.updateOverflowAction`

[bpasero]

Follow up from https://github.com/microsoft/vscode/issues/165441

When profiling window resize on Windows, this method appears as somewhat slow:

This is not entirely surprising, given it checks on container.offsetWidth.

Maybe we can do a bit of debouncing or scheduling on the next animation frame? Editor tabs have a similar problem where we need the container width, but we do debouncing there:

https://github.com/microsoft/vscode/blob/7b70ddcd7647b531970ecc32b14bda66c90be6c9/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1471

Profile:

CPU-20221223T064049.zip

//cc @jrieken

[jrieken]

Maybe we can do a bit of debouncing or scheduling on the next animation frame?

The debouncing will help in the sense of running this less often but we could also attempt to buy more into the measure/modify pattern so that forced layouts happen less likely (see https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/#avoid-forced-synchronous-layouts)