Draft: protocol: add scale120 event to the wl_output

Considering the fractional scale protocol, we can scale our surfaces to any desired values. However, this functionality only applies to surfaces, and before we have the first surface, we don't know the scale factor with floating-point accuracy. Currently, we have a rounded fixed-point scale that may not match the real scale when using fractional scaling.

A significant portion of the code relies on this scale, which runs before window/surface creation. Presently, we encounter situations where a client loads resources during early startup based on the wl_output scale, creates the window, and then receives a smaller scale (e.g., 2 -> 1.5). As a result, the client must redo all the operations to adhere to the new scale. Additionally, some applications may start in the background and lack support for rescaling on the fly.

In my opinion, the current behavior of the fractional scale protocol causes numerous problems for clients. In the majority of situations, we need to obtain the scale factor from wl_output and use viewporter with the received value. I really don't understand why this process is so complex when it could be much simpler.

Additionally, I have noticed that certain code performs its own scale calculation using physical_size / logical_size and obtains a value such as 1.4997070884592854 when, for example, dividing 2560 by 1707. It would be more convenient if the wl_output provided a fractional number directly. Please consider providing us with a fractional number in wl_output.