Allow types from different data models in interfaces

[m-fila]

BEGINRELEASENOTES

• Added possibility to use in the interfaces the datatypes from different podio-based datamodels

ENDRELEASENOTES

The data types had to be aware of interfaces in which they were used in order to make them friend. For instance the types from base model couldn't be made aware of types in model extension so it was impossible to define a model extension with an interface that uses types from base model. #611

It seems the friend internal access was only used to get pointers to internal object in order to define operator< (for usage with maps) by comparing addresses.

In this PR I propose to remove the friend coupling of interfaces and data types. Instead a podio::detail::getRankfree function is added as a friend to each data type. The functions returns unsigned numeric type that can be used for comparisons. According to the standard the most appropriate type here - uintptr_t- is optional, if it's not present then uintmax_t will be used as it's the biggest unsigned type so a pointer will also fit in it.

I had hard time choosing a name for numeric value, that can be used for comparisons and I'm not entirely happy with calling it rank.

Another extension model is used as the extension we had had different getSyntax than the base model which the interfaces can't handle.

[tmadlener]

I think this is a nice solution to the problem. We will potentially need to put some comments into the code as well to explain why we have this (or mention it in some of the documentation).

One potential issue I see with this approach is that we are technically leaking the Obj* addresses to the outside, right? For example, it would be possible to do the following:

MutableHit hit;
auto rank = detail::getRank(hit);
auto hitObjPtr = reinterpret_cast<HitObj*>(rank);
// now we have access to the hitObjPtr!

I don't really see a way to avoid this though at the moment. We would need to have a way to have access to both ranks simultaneously without leaking the actual values to the outside. In the end we probably have to weigh whether this potential leak is worth the additional feature.

What other names did you have on your short list instead of rank?