core: Use g_ascii_strto[u]ll() instead of strto[u]l()

The GLib functions are locale-independent. While there are few
situations where a locale-independent server-provided string would be
parsed differently by strtoul() in different user locales, it’s best to
be safe (and consistent with our use of g_ascii_strtod(), which more
easily causes problems).
tests: Fix GDataAuthorizer:proxy-resolver property tests

The ClientLogin and OAuth 1 authoriser tests were assuming that the
proxy-resolver property is initially NULL. Actually, the property is
only potentially initially NULL, as it comes from a SoupSession which
the tests have no control over.
build: Add missing configure checks spotted by autoscan

Thanks, autoscan!
l10n: Update British English translation
core: Fix a data corruption bug in GDataBuffer

In some situations, the buffer was reading off the end of a chunk and
into undefined memory. Spotted by asan.

e.g. Take a GDataBuffer with two chunks:
 • Chunk 1, length 8192
 • Chunk 2, length 699
and with head_read_offset = 8187 from a previous read. There are thus
704 bytes unread in the buffer.

If a read of 8192 bytes is performed, 5 bytes should come from chunk 1
and the remaining 699 from chunk 2. length_remaining was being
(correctly) set to 704, but then the while loop was not being entered,
as 704 is not greater than or equal to 8192 (the length of chunk 1). The
code was then falling into the G_LIKELY case below, and attempting to
read 704 bytes from offset 8187 of chunk 1 — overreading by 699 bytes
off the end of the chunk, and never getting the 699 bytes from chunk 2.

This can be fixed by correctly taking the head_read_offset into account
for the while condition.
build: Remove outdated documentation checks

These are now performed by gtk-doc. Yay!
freebase: Fix API documentation ‘Since’ versions
core: Fix API documentation ‘Since’ versions
docs: Add the 0.15.1 APIs to the documentation
Release version 0.15.2
build: Increment version to 0.15.3
core: Tweak generated ISO8601 dates to appease Google’s parsers

Even though the protocol documentation claims to accept RFC3339 dates,
the servers have recently started rejecting dates formatted as
‘2014-08-09T21:10:05Z’ which don’t include microseconds and specify the
timezone non-numerically.

Since the issue hasn’t been resolved at Google’s end, we need to hack
the date formats generated by libgdata to appease the servers,
completely undermining the point of having a defined protocol and RFC to
base the code on. Sigh.

Change gdata_parser_int64_to_iso8601() to produce dates in the format
‘YYYY-MM-DDTHH:MM:SS.000001+00:00’. This was previously used by the JSON
output generator, so perhaps the server breakage was introduced when
Google started rolling out the JSON APIs.

https://bugzilla.gnome.org/show_bug.cgi?id=732809
core: Remove outdated gdata_parser_int64_to_json_iso8601()

gdata_parser_int64_to_iso8601() now does exactly the same.

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