refactor: Create disableWhileProcessing helper function

[marcustyphoon]

Description

Just an idea. These are a little weird.

This creates helper functions for:

• withErrorModal: "Wrap this function in showErrorModal to catch errors when it's executed." I find this more clear than writing e.g. event => onButtonClicked(event).catch(showErrorModal). My guess is that this is probably uncontroversial? One question is, would we want to write withErrorModal(someCallback) in the place where it's used, as I did here, or around someCallback where it's defined? The latter breaks jsdoc. Merged in refactor: Create withModalOnError helper function #2129.
• disableWhileProcessing: "Disable a given UI element during the execution of this promise or this block of async code." This might be getting a bit too cute; it's a oneliner shorthand for whatever.disabled = true; try { /* */ } finally { whatever.disabled = false; }.

Notably, the way I wrote the latter involves executing the callback function given to the disableWhileProcessing helper, not returning it, so these can't be used as e.g. withErrorModal(disableWhileProcessing(someElement, someCallback))/disableWhileProcessing(someElement, withErrorModal(someCallback)). That I can think of, you wouldn't generally be able to do this pattern anyway, because someElement probably isn't in scope outside of the callback.

Testing steps

tbd