Plugin Registry:
Have a web-accessible database of plugins from everywhere, including their merit values.  gstplugin.c
and the autoplug code (should we abstract out autoplug into a special file?  I think so) can make use of
this database via another module (gstwebregistry.c?) to look up stuff.  A copy of the registry (gzip'd
XML) could even be cached.  System and user options would determine whether this registry is checked
and/or updated automatically.  The registry could simply be merged with the local machine and user
registries, with the state bit set to "don't even have it".  Autodownload/install code should be
provided, though designed such that it's not toolkit/OS specific.

Merit:
Plugins and even type definition should carry merit values, allowing the system to determine which
plugin or type definition is better.  This can be tied into the web registry setup, where merit values
can be updated without requiring an update of the plugins themselves.  They can also be guaranteed
unique if there's a range reserved for registered objects.  Unfortunately, that might get us into some
political wars.  We could leave that up to the users via some voting system.

Scheduling state:
All the scheduling info for a Bin should be contained in a single object of some form.  This can be
saved off and restored seamlessly at some point in the future.  This would be ideal for some autoplug
cases, where the rest of the pipeline simply ceases to exist temporarily, and scheduling entry points
may need to be modified until the autoplug stage is finished.