reading and writing events leaks memory about podio

[tmadlener]

So there are two different "large" memory leaks, depending on whether we are writing or reading. Large in this case means that memory is leaked for every event. Additionally, there are a few "small" leaks, where we leak only once for the whole execution. (There are also a few other leaks from within the depths of ROOT, but those or not really our concern, I suppose).

The small ones:

• m_table in EventStore (see #134 for a fix)
• temporary l_table in ROOTReader::openFiles (see #135 for a fix)

The large ones:

• When reading we leak all the metadata pointers that are newly allocated by the readers, because, even though the EventStore doesn't really take ownership of the data provided by the reader, but instead copies the data into its members. E.g. here:
  

  podio/src/EventStore.cc

  Lines 89 to 97 in d4a0265

  	GenericParameters& EventStore::getEventMetaData() const {
  	if( m_reader != nullptr ){
  	m_evtMD.clear() ;
  	GenericParameters* tmp = m_reader->readEventMetaData() ;
  	m_evtMD = *tmp ;
  	}
  	return m_evtMD ;
  	}

  
  Moving the data into the internal member and deleting the temporary pointer, fixes this (also fixed in #134)
• When writing the situtation is a bit more complex. Memory is leaked when we create objects with VectorMembers (potentially others too, but definitely with these) outside of collections and then add them to collections via push_back, e.g. in the form of

ExampleWithVectorMemberCollection coll;
auto vec = ExampleWithVectorMember();
coll.push_back(vec)

The problem is that as soon as we push the vec to the collection, it becomes tracked by the collection, and the deconstructor will only delete the internal vector in ExampleWithVectorMemberObj that is allocated via new if it is not tracked. The collection should in principle do this, but does not do it at the moment. Assuming that the object can become invalid as soon as the collection is cleared, then the fix is simply to make the collection properly clean up all its related memory (this is also implemented in #134).