Don't use `gui.char_width` / `char_height` unlike the other GVim
implementations. Those are used for deriving screen pixel sizes and
MacVim has been hard-coding them to 1 for simplicity since the actual
GUI functionality is handled out of the Vim process anyway. Changing
those values would require some refactoring. Instead, just use a new
variable to store them.

Related: vim/vim#16004

Don't use `gui.char_width` / `char_height` unlike the other GVim
implementations. Those are used for deriving screen pixel sizes and
MacVim has been hard-coding them to 1 for simplicity since the actual
GUI functionality is handled out of the Vim process anyway. Changing
those values would require some refactoring. Instead, just use a new
variable to store them.

Note that there is a delay with this method, as we only update Vim's
knowledge of cell size after MacVim has received the font change
message. This means if a user wants to immediately query getcellpixels()
in vimrc or after changing guifont this will not work. This is a
deliberate design choice to avoid having to add synchronous state query
APIs to MacVim, but it's possible to change it in the future. The
handling of this message did get placed in `processInput:` which means
it will be picked up whenever we sleep or process messages in Vim,
instead of only when waiting for keys (where most of other MacVim
messages are handled in `processInputQueue`).

Related: vim/vim#16004

Don't use `gui.char_width` / `char_height` unlike the other GVim
implementations. Those are used for deriving screen pixel sizes and
MacVim has been hard-coding them to 1 for simplicity since the actual
GUI functionality is handled out of the Vim process anyway. Changing
those values would require some refactoring. Instead, just use a new
variable to store them.

Note that there is a delay with this method, as we only update Vim's
knowledge of cell size after MacVim has received the font change
message. This means if a user wants to immediately query getcellpixels()
in vimrc or after changing guifont this will not work. This is a
deliberate design choice to avoid having to add synchronous state query
APIs to MacVim, but it's possible to change it in the future. The
handling of this message did get placed in `processInput:` which means
it will be picked up whenever we sleep or process messages in Vim,
instead of only when waiting for keys (where most of other MacVim
messages are handled in `processInputQueue`).

Related: vim/vim#16004