term.rs: prevent clear_last_lines from deleting input below the cursor

[grunweg]

Right now, when clear_last_lines is called with a value n that is larger than the number of lines before the current cursor position, the top n lines of the terminal are cleared. I would expect that all input below the cursor is left alone.

I see several ways to solve this issue. When there are m lines above the current cursor and clear_last_lines is called with argument n>m, we could:

1. Try to move the cursor down by n-m lines (doing nothing if possible), then clearing the top n lines. In effect, that's the current behaviour.
2. Only clear the top m lines. (Does this crate have a way of emitting a warning to the user? This could be an occasion to emit one; I suspect such code is not doing what the user intended.)
3. Return an error, allowing the user to handle this explicitly.

This PR implements first option (1), documenting this limitation, and adds a proof-of-concept for option (3).

Options (2) and (3) require a way to query the cursor position (to find out how many lines are above the current one). Since this crate doesn't have a way to do so yet, this PR adds one (based on the corresponding ANSI sequence). That code is not complete or polished yet; I'm interested in feedback on the overall approach first.

Currently based in #119 (only last three commits are new); will rebase when that has landed.

[grunweg]

(I've seen the CI failures on windows. Will fix them if it's clear that this direction is worth taking; the code is a prototype anyway.)

[pksunkara]

Please rebase.

[grunweg]

Rebased and squashed commits down to three. Will fix the build on windows if I know the approach is useful.

[grunweg]

I pushed another commit which cleans up the implementation (see commit message for details), along with the formatting. (The MSRV check fails as I'm currently using slice patters, which were only stabilised in Rust 1.48.0.)

I've come to realise that my approach has two significant issues.

• windows support is missing (I've "fixed" the build by cfg-ing out the code). I don't know what must be added there.
  (Relatedly: not every terminal supports the ESC[6n ansi code... although in this case, my code behaves just as previously.)
• the current code requires user interaction to read the terminal response. That's a no-go for most code. AFAICT, reading input from that (e.g. just one character, or a full line) is not quite trivial. This could be fixed using e.g. the termion crate, but that involves another dependency just for an error case.

Hence, I see the options of

• fix the issues above, possibly at the cost of another dependency
• admit that this approach doesn't work easily and switch to approach (1) instead (documenting this limitation)
• manually track the cursor position on the terminal (using a completely different strategy instead)