[Evolution-hackers] Some minor Camel API breaks

[Matthew Barnes <mbarnes redhat com>]

Just for the record, I made a few API changes to Camel over the weekend.

The changes help increase Camel's thread-safety.  One lesson I learned
during the account-mgmt work is when returning a pointer to a reference
counted object in a multi-threaded environment, it's better to return a
new reference to the object which the caller must release.  Otherwise it
introduces potential races where the object might be finalized while the
caller is still using it, or before the caller has a chance to reference
it for safe keeping.

Camel gets this wrong almost everywhere.

Here's what I changed:

* camel_session_add_service() now returns a new reference to the newly
  added CamelService.  The caller must call g_object_unref() on it.

* camel_session_list_services() now returns a list of new references
  to available CamelServices.  The caller must call g_object_unref()
  on each list element before freeing the list.

* camel_session_get_service() is now camel_session_ref_service() and
  returns a new reference to a CamelService.  The caller must call
  g_object_unref() on it.

* Similarly for camel_session_get_service_by_url().

* camel_service_get_settings() is now camel_service_ref_settings() and
  returns a new reference to a CamelSettings.  The caller must call
  g_object_unref() on it.

There's more to be done along these lines but that's all I had in me for
one weekend.

In particular, I still want to rename CamelStore's get_folder() method
to ref_folder() to better reflect its current behavior and since I can
never remember the ownership transfer on that method.  But that might
have to wait until 3.7.

Also some miscellaneous changes:

* Realized CamelSession's forward_to() method blocks and needs to be
  asynchronous, so I "GIO'ized" it with the usual sync+async pattern.

  EMailSession was hacking around this by spawning an async operation
  from within its forward_to() method and then immediately returning
  TRUE as if the whole forward_to() operation were successful.  So it
  lies, basically.

* Killed camel_session_lock/unlock().  Exposing mutexes in a public
  API is just evil and indicates a bad design.  There's still a few
  more of these to kill off.  3.7 material, perhaps.

Matt