Doesn't properly release VTE, causing mem and FD leak

Found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668238

As one uses Terminator, it opens up to 3 files (and immediately unlinks them) per VTE. These files contain the scrollback data.

When a terminal is closed, VTE is actually not properly released (apparently someone's still holding a reference [perhaps a callback, signal, whatever...]), and in turn its file descriptors are not closed. That is:

- All the disk space used by them to store the (potentially unlimited) scrollback remains occupied for the entire lifetime of Terminator, potentially leading to quickly filling up /tmp;

- There's a limit on the open FDs a process can have, it becomes possible that a user with a long-running Terminator hits this limit.

I've tried explicitly calling gc.collect() but it didn't help, closing these files is not just slightly deferred due to GC's nature, they are not closed at all.

---

How to reproduce:

- Start Terminator with a couple of terminals;

- In each of them produce lot of output including various colors;

- ls -l /proc/[terminator's pid]/fd;

- Notice 3 file descriptors for each VTE pointing to "/tmp/blahblah (deleted)";

- Close some of the terminals;

- Notice that their files are still open.

- If you really produce a lot (like, really a lot) of data in these terminals with infinite scrollback, you can also see "df" reporting a shrinking /tmp.

- If you add a debug printf to vte's vte_terminal_finalize(), you'll see that it's not called.

Expected behavior:

- When a terminal is closed, its 3 file descriptors should disappear from this listing, and correspondingly (at any time, the number of such deleted open files should be at most 3 times the number of open terminals). The available disk space ("df") under /tmp should grow back.

- The debug printf should tell you that vte_terminal_finalize() is executed.

---

A bit of technical background:

Each VTE creates 3 streams for the scrollback contents. One is for the plain text. The other is for colors and other attributes, using a runlength encoding (to--from coordinates for each continuous run of identical attributes). The third one contains pointers to the first two for each pyisical line of the buffer.

Each stream is flushed to disk after every 64kB of data. The file is only created at the first write, that is, when 64kB is already written to that stream.

There's compression, encryption, and a weird mapping to get a circular buffer if the scrollback is finite large, I'm not going into these details here.

If the teminal's contents consists of plain non-colored single-wide characters only, the file containing the attributes won't grow and hence this stream won't hit the disk. Therefore if you wish to see 3 file descriptors appearing, you need to produce various colors, or double-wide (CJK) characters; a giant plain English text will only get you 2 files.

When the terminal's contents are rewrapped on a resize, 1 of the 3 streams (the one with the row indexes) is regenerated and the old one is thrown away (and so is the underlying file). Therefore when a terminal is resized, you might face the number of opened files decreasing by 1.

I'm writing these so that you don't get into too many unknowns and wtfs while debugging :)