fix: fixed some read-only mode buttons bugs

[SystemChanger]

Fixes:

1. "setToolbarButtons()" now correctly caches buttons to "resizingDisabledButtons" array.
   As it was: buttons were cached before being changed by this code:

let plugin, button, oldButton;
for (let key in pluginCallButtons) {
    if (!util.hasOwn(pluginCallButtons, key)) continue;
    plugin = plugins[key];
    button = pluginCallButtons[key];
    if (plugin.active && button) {
        oldButton = oldCallButtons[key];
        core.callPlugin(key, null, oldButton || button);
        if (oldButton) {
            button.parentElement.replaceChild(oldButton, button);
            pluginCallButtons[key] = oldButton;
        }
    }
}

As a result, they weren't disabled on the "readOnly()" invocations.

2. "setToolbarButtons()" now don't enable buttons disabled by "readOnly()".
   As it was: On window resize (and other events with "setToolbarButtons()" invocation) buttons lost their "disabled" state.
   (check the second point in "Suggestions" below)

3. Removed the "se-readonly-enabled" class from "Undo" and "Redo" buttons constructor.
   As it was: they had this class, but anyway were "returned" in their handlers cause of readOnly.
   Obviously, they don't need them.

4. Now, read-only mode allows hiding more layer when the "more" button is pressed. Bonus: little code refactor.
   As it was: the "more" button didn't react on pressing and hiding the layer in read-only mode.

Suggestions: (#835 issue)

1. Why "se-resizing-enabled" class and the corresponding array "resizingDisabledButtons" are called so?
   This is super strange, They should be called something like "se-readonly-enabled" and "readOnlyDisabledButtons".
   Version 3.0.0 ? :)

2. I think that it is better to copy all properties of previous toolbar buttons to the new ones in "setToolbarButtons()" method, cause in the future there could be some other stuff besides read-only, fullscreen or codeView (or is already there).
   Check the issue ToolbarButtons code and functionality enhancements #835 for more details.

3. In addition, it'll be good to have "onSetToolbarButtons(buttonList)" user-definable event function to declare the custom buttons css and properties (ofc we can override this method, but it'll be cleaner for users with the knowledge that they have to do this for custom buttons).
   UPD. Created a separate pull request for "onSetToolbarButtons()" event:
   enhancement: added "onSetToolbarButtons" event #834

[SystemChanger]

Fixes:

5. Now closes active menus, which buttons were disabled by setting the read-only.
As it was: menus buttons could be pressed even if their parents (Dropdown buttons) were disabled.
6. Now, custom buttons designed for read-only (with "se-resizing-enabled" class) can invoke handlers in read-only mode. As it was: custom buttons (plugins) weren't able to invoke their callBackFunctions regardless of the presence of the "se-resizing-enabled" class.

We are getting close to the reason I started this all "read-only" adjustments ;)

[SystemChanger]

There is no need in this line if you will apply the changes from #839 pull-request

[JiHong88]

@SystemChanger Thank you for your contribution.!
"se-resizing-enabled" is a variable created before "readonly" mode development.
These are buttons that are not deactivated when selecting images, etc.
It is also used in "readonly" mode.

[JiHong88]

@SystemChanger The 2.42.0 version has been updated.
If this issue has not been resolved, please reopen this issue.
Thank you.