CamelService: Remove all asynchronous class methods.

Rationale:

When I originally added Camel's asynchronous API, I thought providers
could choose to override the synchronous or asynchronous class methods.

Years later, turns out the asynchronous methods were never overridden,
and it wouldn't have worked anyway.  The asynchronous methods by default
invoke an associated synchronous function from a worker thread, but many
of Camel's synchronous functions do extra processing around invoking the
synchronous class method.  camel_store_get_folder_sync() is an example.

If a provider tried to implement synchronous methods in terms of the
asynchronous methods, then that extra processing in the synchronous
functions could potentially get skipped.

Removing the asynchronous class methods should help clarify how Camel
providers are intended to be written.

The removal should have no impact on existing Camel providers, all of
which implement only the synchronous class methods.  I've even padded
the CamelServiceClass struct to keep the binary interface intact.
CamelStore: Remove all asynchronous class methods.

Rationale:

When I originally added Camel's asynchronous API, I thought providers
could choose to override the synchronous or asynchronous class methods.

Years later, turns out the asynchronous methods were never overridden,
and it wouldn't have worked anyway.  The asynchronous methods by default
invoke an associated synchronous function from a worker thread, but many
of Camel's synchronous functions do extra processing around invoking the
synchronous class method.  camel_store_get_folder_sync() is an example.

If a provider tried to implement synchronous methods in terms of the
asynchronous methods, then that extra processing in the synchronous
functions could potentially get skipped.

Removing the asynchronous class methods should help clarify how Camel
providers are intended to be written.

The removal should have no impact on existing Camel providers, all of
which implement only the synchronous class methods.  I've even padded
the CamelStoreClass struct to keep the binary interface intact.
CamelTransport: Remove all asynchronous class methods.

Rationale:

When I originally added Camel's asynchronous API, I thought providers
could choose to override the synchronous or asynchronous class methods.

Years later, turns out the asynchronous methods were never overridden,
and it wouldn't have worked anyway.  The asynchronous methods by default
invoke an associated synchronous function from a worker thread, but many
of Camel's synchronous functions do extra processing around invoking the
synchronous class method.  camel_store_get_folder_sync() is an example.

If a provider tried to implement synchronous methods in terms of the
asynchronous methods, then that extra processing in the synchronous
functions could potentially get skipped.

Removing the asynchronous class methods should help clarify how Camel
providers are intended to be written.

The removal should have no impact on existing Camel providers, all of
which implement only the synchronous class methods.  I've even padded
the CamelTransportClass struct to keep the binary interface intact.
CamelSubscribable: Remove all asynchronous class methods.

Rationale:

When I originally added Camel's asynchronous API, I thought providers
could choose to override the synchronous or asynchronous class methods.

Years later, turns out the asynchronous methods were never overridden,
and it wouldn't have worked anyway.  The asynchronous methods by default
invoke an associated synchronous function from a worker thread, but many
of Camel's synchronous functions do extra processing around invoking the
synchronous class method.  camel_store_get_folder_sync() is an example.

If a provider tried to implement synchronous methods in terms of the
asynchronous methods, then that extra processing in the synchronous
functions could potentially get skipped.

Removing the asynchronous class methods should help clarify how Camel
providers are intended to be written.

The removal should have no impact on existing Camel providers, all of
which implement only the synchronous class methods.  I've even padded
the CamelSubscribableInterface struct to keep the binary interface
intact.
CamelFolder: Remove all asynchronous class methods.

Rationale:

When I originally added Camel's asynchronous API, I thought providers
could choose to override the synchronous or asynchronous class methods.

Years later, turns out the asynchronous methods were never overridden,
and it wouldn't have worked anyway.  The asynchronous methods by default
invoke an associated synchronous function from a worker thread, but many
of Camel's synchronous functions do extra processing around invoking the
synchronous class method.  camel_store_get_folder_sync() is an example.

If a provider tried to implement synchronous methods in terms of the
asynchronous methods, then that extra processing in the synchronous
functions could potentially get skipped.

Removing the asynchronous class methods should help clarify how Camel
providers are intended to be written.

The removal should have no impact on existing Camel providers, all of
which implement only the synchronous class methods.  I've even padded
the CamelFolderClass struct to keep the binary interface intact.
CamelFolder: Remove unused fetch_messages_sync() method.

The method is not used by Evolution and was partially broken anyway.
The boolean return value was overloaded to mean both whether an error
occurred AND whether there were more messages to fetch.  That's more
than two possible states and would have required an additional "out"
parameter to clarify, but I'm not going to bother with it.
CamelPOP3Settings: Remove unused "mobile-mode" property.

Not used by Evolution and not clear what this mode even means.

Removing it makes a bunch of confusing complexity drop out, which is
justification enough for me.
CamelPOP3Settings: Remove unused "batch-fetch-count" property.

Was tied to "mobile mode", no longer used.
CamelIMAPXSettings: Remove unused "mobile-mode" property.

Not used by Evolution and not clear what this mode even means.

Removing it makes a bunch of confusing complexity drop out, which is
justication enough for me.