Firstly notice that the performance is about irrelevant within this diff, because all code triggered is only called upon closing the page,
and because all code triggered takes some milliseconds to complete.
To demonstrate completeness of the diff, search the json file for the callback string and see that all of them were removed and superseded.
To demonstrate the correctness of the diff in a blackbox test:
* Toggle the diplomacy color minimap button
* Change the batch train size in the options page and queue batch trains
* Use the hotkeys and options page to toggle the different auras
* Add `warn` to the update functions and see that they are only called if an according hotkey had been pressed or an according checkbox in the options page toggled
* Compare the previous rangeoverlaymanager code to the new one and notice it does the same
* Train and select a healer and use the hotkey
* Use building preview for towers and use the hotkey
* Notice the options page and hotkey changes modify the same config value at the same time and are in sync
* Notice that a Set is nicer than array for insertion and existence lookup, but doesn't allow for array functions such as `changes.some(change => ...)` without array creation which in turn is discouraged since it costs some cpu cycles without being necessary
* Notice the word "callback" is gone from options.js
* Notice there is a hotkey setter but no reaction using registerHotkeyChangHandler. Thats because the SetGlobalHotkey function needs rework to support more types and because meh not now, it's a placeholder event currently anyhow.
* Notice the RangeOverlayManager is complete, i.e. the word rangeoverlay doesn't appear anymore in session/ elsewhere.
* Notice how RangeOverlayManager.prototype.Types is cleaner and more extensible than the previous string construction.
* Notice that the RangeOverlayManager types are identical in behavior, not granting a warrant to make those three individiual class, currently that it.
* Search on irclogs, trac, Phabricator and svn repository to find evidence of suffering due to the session hardcoding in the options page.
* Notice that the fire function should actually be deleted in the future and superseded by one that is fired from the config code, but that all the rest of the code will remain the same, so the workaround part (if considered such at all) is limited to the fire function, but the consumers of the event will remain the same (which is the more significant part of the diff).