[WIP] Schema evolution registry population

[tmadlener]

BEGINRELEASENOTES

• Thank you for writing the text to appear in the release notes. It will show up
  exactly as it appears between the two bold lines
• ...

ENDRELEASENOTES

• Needs Add schema evolution hooks to Frame #413 (builds on top of that)

This will be a (partial) completion of the work in #413 as this will actually start to populate the SchemaEvolution registry that was introduced there. Additionally, this will add (more) tests for checking whether writing data with schema version 1 can be read back using schema version 2 of the test datalayout. My current thinking is that code generation will come in another PR still, once the basic functionality has been tested end-to-end using manually implemented evolution functionality.

@hegner the schema evolution tests are currently failing, because apparently ROOT is not able to do the "trivial" schema evolution of adding (and default initializing) new member variables. My thinking was that this would work out of the box, but apparently I am doing something wrong at the moment.

[tmadlener]

My earlier tests were unsuccessful due to a wrong test environment, fixing that and populating the SchemaEvolution registry with the trivial evolution function makes some of the evolutions work with ROOT.

[tmadlener]

A new test for the renamed member variable fails, because ROOT cannot handle this on its own. This will require some work:

• The CollectionBufferFactory has to be made aware of the Backend
• There needs to be logic in the population of the factory, but also during calling to handle the Backend as additional condition
• evolution function (manual to start with)

[hegner]

A new test for the renamed member variable fails, because ROOT cannot handle this on its own.

That is correct. Renaming ROOT is not able to understand / auto-derive

[tmadlener]

superseeded by #441