`buffer.actions` is a doubly-linked list, so
`action_to_(undo|redo)` could potentially point to itself
if it is the only item in the list. current coarse undo
code will fall into an infinite loop by failing to check
for this. this patch fixes.

`bview_t.viewport_bline` is a pointer to the line where we want to
begin rendering the buffer. if an action takes place that frees the
line pointed to by `viewport_bline`, and we don't safely update
`viewport_bline` before using it, we can potentially segfault. this
happened while playing around with coarse_undo (feature coming
shortly), in which `_bview_buffer_callback` attempted to use
`viewport_bline` after it had been freed.

marks are already maintained within buffer code, including the case
of a mark's line getting deleted. all buffer operations are
guaranteed to rectify all marks before returning, so it is safer to
use a mark instead of a bline pointer to denote the viewport.

this bug surfaced as a blank display after `C-q p` or `C-q o`
commands, both of which involve replacing the buffer of an existing
bview. `git bisect` pointed to commit dd283981. stepping through
`buffer_get_bline_w_hint` revealed that we were using a freed bline
as our `opt_hint`, which caused that function to always return
`last_line`, which in turn broke a bunch of stuff. so the bug existed
before this commit, but it was silent. reproducing through valgrind
yielded the following:

```
Invalid read of size 8
   at 0x1375D6: buffer_get_bline_w_hint (buffer.c:715)
   by 0x11B93A: bview_rectify_viewport (bview.c:388)
   by 0x11BE08: bview_resize (bview.c:147)
   by 0x11C41B: bview_open (bview.c:67)
   by 0x1417E5: _cmd_fsearch_inner (cmd.c:1805)
   by 0x13C8A9: cmd_fsearch (cmd.c:605)
   by 0x1238E6: _editor_loop (editor.c:927)
   by 0x11CE51: editor_run (editor.c:153)
   by 0x12EDE0: main (main.c:20)
 Address 0x5257130 is 32 bytes inside a block of size 128 free'd
   at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/...
   by 0x13969F: _buffer_bline_free (buffer.c:1493)
   by 0x135C68: buffer_destroy (buffer.c:205)
   by 0x11B3E4: _bview_deinit (bview.c:599)
   by 0x11C2B8: _bview_init (bview.c:451)
   by 0x11C2B8: bview_open (bview.c:66)
   by 0x1417E5: _cmd_fsearch_inner (cmd.c:1805)
   by 0x13C8A9: cmd_fsearch (cmd.c:605)
   by 0x1238E6: _editor_loop (editor.c:927)
   by 0x11CE51: editor_run (editor.c:153)
   by 0x12EDE0: main (main.c:20)
```

unsetting `viewport_bline` in `_bview_deinit` fixes the bug. other
objects like cursors, marks, srules, etc. which hold bline pointers
are already deinit'd in this function, so we should be covered there.

this is another case where smart pointers might have been useful.

it's hard to write a test for this one as it involves viewport code which
is not executed in headless mode (which tests run in).

idea copied from @PJayB https://github.com/tomas/eon/pull/2

`buffer_get_bline_w_hint` begins the bline hunt at a
parameterized bline instead of always starting at the first
bline in the buffer. when editing huge files with millions
of lines, there is a noticeable perf improvement if the
hint is nearby the desired bline.

also a perf improvement to bail the render loop if we are
already off screen.

https://duckduckgo.com/?q=xclip+does+not+close+stdout