Use of object IDs is broken in seahorse

[Stef <stef-list memberwebs com>]

I've committed a bunch of changes that try to fix things up to be usable
in this release. There's been a swath of bugs with object IDs and object
ownership.

Currently for an object (such as a key, password or identity/uid) to be
generally available in seahorse it needs to be owned by the
SeahorseContext. Only such objects are then available via DBus, or show
up in the interface.

In order to be owned by the context an object has to have a unique (to
its source) ID.

A SeahorseSource of an object is where an object came from (what loaded
it). Sources represent keyrings, etc...

The ID is also used by things that need to track objects between runs of
the program (ie: configuration, default key settings etc.). The object
id is also used to correlate objects from different sources (eg: same
key on keyserver and local).

However for some objects we don't know the ID right away and can only
build an ID after loading further information about the object (PKCS#11
is an example here).

As part of the work for 2.28, I'd like to move the focus away from every
object (key, password item etc.) having to have an ID. If it has one,
then great, it can be used in the above operations that require an ID.
But it's not required, and the application doesn't expect it throughout.

In addition I'd like to move toward the sources owning the objects. Each
object will then register with the context (and unregister when
destroyed) in order to make itself discoverable and usable.

Anyway, that's just an explanation of why this is broken, and how
hopefully we'll get something sane in the future :)

Cheers,

Stef