bugfix: avoid drawing text below edit.bottom

So far I've only thought of the early returns in get_rect/compute_rects
as optimizations, but it turns out they are important to get right just
when called by edit.draw.

We're still not clipping drawings below edit.bottom, but there isn't yet
a fork that exercises this scenario, with edit.bottom above the window
bottom. Still ugly that drawings clobber the bottom margin, but the
alternative is also weird in many situations..

extract a variable

rename a var

move

simplify a helper

make the wrap indicator look like a hyphen when splitting word

indent wrapping lines and show a lame indicator

I ended up backporting draw commands from text2.love for this. Perhaps I
should also backport support for the other two experimental features
`show_cursor` and `conceal`. But to my mind lines.love is a
self-contained app where text2.love is more intended for reuse, the root
for a family of forks, etc. I'm following YAGNI more strongly here, not
concerned about namespace pollution, etc.

I really wish I had this feature in capture.love and pensieve.love.
That'll take some doing since they're using the old editor
implementation. Perhaps I should create capture2.love, that would be
easy at least..

Conversely, I'm not going to pull this feature yet into text2.love and
downstream forks. lines2.love is pretty disconnected both upstream and
downstream. text2.love has other bells and whistles, and this would be
yet another optional arg.

I need to start to figure out how to systematize the arg list for
text2.love. I'm starting to think in terms of Emacs's buffer type:
  https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Buffer-Type

refactor

bugfix

scenario: click below bottom margin

Before this PR the cursor would disappear out of view.

This is also disquieting.
- When did I fail to test for it? Looks like my original implementation
  handled it fine, but it crept into the yumaikas-experiment branch.
- Am I creating new bugs when I fix bugs now? I've gone through all the
  manual and automated tests in the main lines.love repo, and everything
  seems fine.

Now I'm backporting this from text2 to lines2 and not bothering to redo
all the manual tests.

Is the maxy check still valid now that we have drawings? I think so.
edit.draw doesn't show the top of a drawing if there's less than
editor.line_height of vertical space left. The important thing is to
keep to_loc in sync with that. You can't position the cursor on a
character you didn't draw this frame.

simplify nil return that never happens anymore

fix another outdated name

fix some outdated names

bugfix in search UI

Scenario:
  position cursor before final character of a line
  press C-f
  press down arrow

Before this commit the app would crash.

bugfix

Scenario:
  open a (new) file in the editor
  type some text into a file (so cursor is not at the start)
  close the editor
  delete the file
  reopen the editor without specifying a file

Before this commit, the cursor wouldn't be visible (it's off the end of
the file), and typing any letters would crash the editor.

drop nativefs

I've seen several reports of unreliability recently:
* Doesn't work with LÖVE v11.5 on iPads
* Doesn't work with LÖVE as distributed with Gentoo Linux (which is
  compiled with PUC Lua rather than LuaJIT)

delete dead code

bugfix: searching upwards wraps to bottom of file

transparent highlights work with more colors

support drawing variable-height cursor

Not used in this fork, but handy.

disquieting bugfix

Scenario: shift-click somewhere
Before this commit it would select nothing.

This is disquieting because I'm again starting to worry about whether
I'm testing enough, considering all the scenarios. This is a fairly
obvious one. It's been in there since commit 70c0844acd back on Jul 19.

Anyways, I've tested a few different scenarios and everything seems to
still work:
  - click
  - shift-click
  - shift + cursor movement keys
  - select across a drawing
  - drag then press shift while dragging