Check that the data is expanded with zeros.

For GMemoryOutputStream, update valid_len when truncating so that
g_memory_output_stream_get_data_size () returns the correct result.

https://bugzilla.gnome.org/show_bug.cgi?id=720080

Be a little bit more careful in regards to initializing a primitive type
variable before passing it by reference, as it could have random stuff
in the variable's address depending on the CRT, such as MSVCR110.DLL,
causing random, invalid stuff being written in that address.

This will fix this test when built with Visual Studio 2012.

https://bugzilla.gnome.org/show_bug.cgi?id=711047

Improve test coverage for testing seeking on fixed vs. resizable
GMemoryOutputStream.

https://bugzilla.gnome.org/show_bug.cgi?id=684842

It is our intention that memory output streams should operate in two
distinct modes, depending on if a realloc function was provided or not.

In the case that we have a realloc function (resizable mode), we want
the stream to behave as if it were a file that started out empty.  In
the case that we don't have a realloc function (fixed-sized mode), we
want the stream to behave as a block device would.

To this end, we introduce two changes in functionality:

 - seeking to SEEK_END on a resizable stream will now seek to the end of
   the valid data region, not to the end of the allocated memory (which
   is really just an implementation detail)

 - seeks past the end of the allocated memory size are now permitted,
   but only on resizable streams.  The next write will grow the buffer
   (inserting zeros between).

Some tweaks to testcases were required in order not to break the build,
which indicates that this is an API break, but it seems unlikely that
anyone will be effected by these changes 'in the real world'.

Updates to documentation and further testcases are in following commits.

Based on a patch from Maciej Piechotka <uzytkownik2@gmail.com>.

https://bugzilla.gnome.org/show_bug.cgi?id=684842

Really, the memory output stream API is too warped around the model
where it's a fixed size buffer that you've already allocated.  Even in
C, I find myself always wanting to use it to just accumulate data into
an arbitrary-sized buffer it allocates.

Unfortunately, it's also not usable from bindings because it's not
common to bind g_free() and g_realloc(), but if you just pass NULL, you
get the default of a fixed size, which is useless as per above.

I am going to use this from a gjs test case, and the GSubprocess test
cases also will use it.

https://bugzilla.gnome.org/show_bug.cgi?id=688931

Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().

Remove those uses, as they are no longer required.

https://bugzilla.gnome.org/show_bug.cgi?id=686161

Using a caller-supplied buffer for g_input_stream_read() doesn't
translate well to the semantics of many other languages, and using a
non-refcounted buffer for read_async() and write_async() makes it
impossible to manage the memory correctly currently in
garbage-collected languages.

Fix both of these issues by adding a new set of methods that work with
GBytes objects rather than plain buffers.

https://bugzilla.gnome.org/show_bug.cgi?id=671139

Matches the corresponding additions to GMemoryInputStream.

https://bugzilla.gnome.org/show_bug.cgi?id=672102