Actually it was being cause by a failure to reset
`(QPoint) TConsole::P_begin` and `(QPoint) TConsole::P_end` - which are
used to record the selection in the event that the `TBuffer` was empty or
for some other reason the selection was not found when called from
`selectString(...)` which uses `(int) TConsole::select(const QString, int)`.

There was also a Hindenbug lying in `TConsole::insertLink(...)` and
`TConsole::insertText(...)` where if `buffer.buffer.empty()` was `true`,
execution would then proceed to evaluate `buffer.buffer[0].empty()` which
is undefined behaviour because there would not **be** a `buffer.buffer[0]`!

This should close Mudlet#4634 - which I have reproduced in the current
`development` branch code with the following function:
```lua
function testCut()

clearWindow()
feedTriggers("This is a test line.\n")
selectString(line, 1)
cut()

tempTimer(3, "feedTriggers(\"This is a second test line.\n\")")

tempTimer(6, "selectString(line, 1) cut()")

end
```

After the first time this is called, repeats will crash Mudlet when the 6
second delayed `selectString(line, 1) cut()` is called. One thing to note
is that this code actually fails to follow the Wiki guidance for
**[`selectString(...)`](https://wiki.mudlet.org/w/Manual:Lua_Functions#selectString)**
which says "Note: To prevent working on random text if your selection
didn't actually select anything, check the -1 return code before doing
changes"!

/claim Mudlet#4634

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>