FilteredStorage::createCollection() needs to set the correct source and filtered storages on filters

After calling FilteredStorage::createCollection() a new instance of FilteredStorage is returned that is correctly set up with the new collection and the respective filters.

The filters, however, do not have their source and filtered storages set up correctly. If the filter does not override ConfigFilterBase::filterCreateCollection() this means that the old instances of the source and filter storages are still held in the filters, i.e. those with the previous (incorrect) collection. If a filter (correctly) creates a new instance of itself (like TestSplitFilter, the source and filtered storage will not be set at all. In both cases, bugs will arise when using the source or filtered storage.

The attached patch fixes this by setting the source and filtered storage just like in FilteredStorage::__construct().

It also modifies ConfigFilterBase::createCollection() to actually clone the filter (since it is not really possible construct a new instance in a generic way) so that a new instance is returned.

Furthermore, I also added a note about creating a new instance to the docs of ConfigFilterInterface::filterCreateCollection().

Lastly, I noticed that the keys that the filters are internally keyed by are not retained by FilteredStorage::createCollection(). Although the keys are not necessarily an API that anyone should rely on, but I do think it is strange that the data structure is inconsistent between ::createCollection() having or not having been called prior. I hope it's OK to include this here, even though it's not strictly in scope of the bug.