[Kst] Architectural changes

[Barth Netterfield]

After going through in detail the use of <Object>Ptrs in kst last week, I 
found and removed a couple places that were causing some our memory leaks and 
crashes, or at least causing KstSharedPtr to not delete things when it should 
(and to delete things when it shouldn't). 

The Store is basically a list, with a couple convenience functions thrown in 
(template functions to create and find objects).  I think that this is how it 
should probably stay.

Kst uses KstSharedPtr, which does in fact seem to work just fine.  I don't 
think we should change that either.
	(Note: KstSharedPtr has the huge advantage over a QSharedPtr that it stores 
its reference count in the object itself, so a KstSharedPtr can be converted 
into a bare pointer, passed somewhere, and converted back into a KstSharedPtr, 
and the reference count is happily carried over.  Not so for QSharedPtr, which 
holds the reference count in the pointer itself.)

The last big 'under-the-hood' work is related to locking.  Currently, we are 
not multi-threaded, except for some stuff related to data-source 
initialization, so any locking troubles we might have, we don't currently 
face.  This will need to be fixed.  I propose we delay this until after 2.0.

So:  From now to 2.0, we should work only on critical bug fixes and critical 
or very easy feature fixes, which a goal of a 2.0 release on the weekend of 
January 1.

The exception to this would be if we find a reason we would need to do an API 
change to data-sources or plugins, in which case the Jan 1 release would be 
called '2.0-beta4'

Thoughts?

cbn