Implement only the test target, not check

At the moment our tests requires to be run inside a clean
dbus/xvfb session, which is not always available where the
check target is used (for example in distcheck). Also when
running distcheck in buildbot we don't really want to run
tests again, since we just run them in the check step.

We might revisit this in the future but using a non standard
target is the easiest solution for now.
Use xz for distribution

It has better compression.
Release 0.99.0
Move activity update code to jarabe.model

In preparation for implementing automatic/background activity updates,
move the code from an extension-specific model into jarabe.

The main update code is now in jarabe.model.update and the downloader
has been made generic and moved to jarabe.util.downloader. It now
downloads files into the temporary 'data' directory which is cleaned up
on every Sugar launch, avoiding leaving stale files around in failure
cases.
Don't initialise GTK+/dbus thread support

These calls allow GTK+ and dbus to be used from other threads.
Sugar doesn't currently create any threads, so these calls aren't
needed.

This is useful for followup work where some main loop recursion
results in a function that is sometimes called with the GDK threads lock
held, and sometimes without it held. By disabling this threading support,
this lock (and the surrounding headache) goes away.

By not activating the threading lock, we should also have a minor
performance increase.

Threads can still be used if desired, but all GTK+ calls should be made
from the main thread. These functions have actually been deprecated
in GTK+ 3.6 as the developers have determined that "draw from one thread"
is the way to go.

The GLib.threads_init() call is still needed, as we do have users
that work with threads, so the GIL must be released accordingly. However it
can be removed once pygobject-3.10 is a requirement:
https://bugzilla.gnome.org/show_bug.cgi?id=686914
bundleregistry: Add asynchronous install capabilities

In preparation for automatic activity updates, add asynchronous install
capabilities to the bundleregistry.

The synchronous install implementation has been removed and is now a user
of the async API that waits for completion before returning.

In order to avoid painful corner cases, the bundleregistry maintains
a queue of bundles to install, and installs them one by one. Install is
done in another thread to not block the main one.

As the install thread requires brief access to the list of bundles in the
bundle registry, all accesses to bundleregistry._bundles are now serialized
with a lock.
updater: asynchronously update bundles

This means that we unblock the main thread, a crucial step
towards offering automatic background activity updates.
Automatic activity updates

A new auto_update_frequency gconf key (default 0, disabled) enables
automatic activity update at an interval specified in days.

Sugar checks if this threshold has been met 10 minutes after launch,
and then every hour.

Activity upgrades are done completely in the background, but if the
user opens the updater control panel section while an update is in
progress, the background update is effectively brought into the
foreground and the user can monitor its progress.

This required a bit of view/model rework so that the view can be regarded
as a client that can attach at any point during the update process.
Implement urgent background activity updates

Dropping an empty .sugar-update flag file in the home directory will
now trigger an automatic background activity update ran as soon as
network connectivity is available.

This is designed for use after a system upgrade. Upon major Sugar and OS
upgrades, user activities will often need to be updated to new APIs, etc.
The system upgrade tool should put this file in place, which will then
trigger Sugar to try hard to update the user's activities.

This replaces the previous use of the .sugar-update functionality,
which was to show a message advising activity update, which turned out
to be somewhat ineffective in the field.
Activity updater: move activity check logic into backend

Right now, the activity updater assumes that the backend requires one
query per installed bundle. That won't be true for the OLPC microformat
updater.

Move the query-by-query checking logic into the ASLO backend, turning
it into a class at the same time, in order to ease state tracking.
Refactor BundleUpdate to allow for new activities

The upcoming OLPC microformat backend presents the opportunity to install
new bundles where no previous version was installed.

Refactor the updater to make way for this. The main change is making
BundleUpdate work in terms of a bundle ID and name, rather than an
installed Bundle.
OLPC microformat activity updater

Implement support for the widely-deployed OLPC activity microformat,
according to
http://wiki.sugarlabs.org/go/Features/Automatic_activity_updates

A new helper class was added to be able to perform partial HTTP reads.
When combined with the ZipFile class, we can download specific parts of
zip archives without having to downloda the whole archive. We do this
when we have to look up the localized activity name of a new activity.
Microformat updater: skip name lookup for automated updates

We normally go to some lengths to make sure that we present the
localized activity name in the UI. However, if we are doing an
automatic background update, there is no UI, so we can skip the
online name lookup in cases where it would otherwise be necessary.