Account for "line-spacing" when calculating rows for side-window-right

[mmarshall540]

This is related to Issue #205. After leaving a comment, I discovered that I could only recreate the problem if Emacs's line-spacing variable was set to a positive number.

The line-spacing variable adds space between lines, thereby reducing the number of lines in a frame. It can have a per-frame value, but that'll be overridden if the global line-spacing variable has been set, e.g. through the customize interface.

On graphical terminals, you can specify the line spacing for all lines in a frame, using the line-spacing frame parameter (see Layout Parameters). However, if the default value of line-spacing is non-nil, it overrides the frame’s line-spacing parameter. An integer specifies the number of pixels put below lines. A floating-point number specifies the spacing relative to the frame’s default line height.
(from https://www.gnu.org/software/emacs/manual/html_node/elisp/Line-Height.html)

It appears that the built-in frame-height function simply calculates a number of rows by dividing pixel height by the default character size. But it doesn't account for the additional space used by line-spacing. In turn, this causes which-key's side-window-right configuration to overlap the modeline whenever line-spacing has been set to a positive value.

For example, on my system:
(frame-char-height) returns 17, and (frame-pixel-height) returns 1080. Dividing 1080 by 17 and rounding downward would give a row count of 63, which is the number that (frame-height) returns. If we subtract 2 for the modeline and echo area, we would expect to have 61 visible rows of text.

I can confirm this with line-spacing set to nil. I turn on global-linum-mode, and go to the top of a buffer and see 61 fully visible lines of text.

But if I set line-spacing to 0.1, (frame-height) still returns 63. Then if I go to the top of my buffer again, I can see that the number of visible rows was reduced to 58.

This is just using the pixel based measurements to get a more accurate row count. It fixes the issue for me. And I'm certainly open to any feedback or discussion.

Pull requests are welcome as long as the following apply.

1. The issue you are fixing or feature you are adding is clearly described and/or referenced in the pull request or github issue.
2. Since which-key is on GNU ELPA, any legally significant changes must have their copyright assigned to the FSF (more info). If you have not done so and would like to assign copyright, please see the request form. This process is easy, but can be slow.

Not sure if it's needed for such a small contribution, but I went ahead and emailed the form in.

Been enjoying this package very much for a while now. Thank you and best regards!