Remove the timed part of the terminal paste mechanism.

In r10020 I carefully reimplemented using timing.c and callback.c the
same policy for large pastes that the previous code appeared to be
implementing ad-hoc, which included a 450ms delay between sending
successive lines of pasted text if no visible acknowledgment of the
just-sent line (in the form of a \n or \r) came back from the
application.

However, it turns out that that *wasn't* what the old code was doing.
It *would* have done that, but for the bug that it never actually set
the 'last_paste' variable, and never has done since it was first
introduced way back in r516! So the policy I thought had been in force
forever has in fact only been in force since I unwittingly fixed that
bug in r10020 - and it turns out to be a bad idea, breaking pastes
into vi in particular.

So I've removed the timed paste code completely, on the basis that
it's never actually worked and nobody seems to have been unhappy about
that. Now we still break large pastes into separate lines and send
them in successive top-level callbacks, and the user can still press a
key to interrupt a paste if they manage to catch it still going on,
but there's no attempted *delay* any more.

(It's possible that what I *really* ought to be doing is calling
back->sendbuffer() to see whether the backend is consuming the data
pasted so far, and if not, deferring the rest of the paste until the
send buffer becomes smaller. Then we could have pasting be delayed by
back-pressure from the recipient, and still manually interruptible
during that delay, but not have it delayed by anything else. But what
we have here should at least manage to be equivalent to the *actual*
rather than the intended old policy.)

[originally from svn r10041]
[r516 == 0d5d39064a]
[r10020 == 7be9af74ec]

terminal.h

@@ -223,7 +223,6 @@ struct terminal_tag {
 
     wchar_t *paste_buffer;
     int paste_len, paste_pos;
-    Terminal *paste_timer_ctx;
 
     void (*resize_fn)(void *, int, int);
     void *resize_ctx;