Make it possible to construct collections from ranges of handles

[tmadlener]

BEGINRELEASENOTES

• Add a from factory function to create collections from ranges of (mutable or immutable) handles

ENDRELEASENOTES

• Includes Make link collection iterators behave consistently with generated collection iterators #922
• Proper documentation (once it's decided that this is useful)

See discussion in #778 for some motivation of this.

@wdconinc this is a first attempt at addressing at least part of the issue discussed in #778. It allows to construct collections from ranges (satisfying std::input_range) of handles, e.g.

std::vector<edm4hep::MCParticles> particles; // from wherever
auto mcParticles = edm4hep::MCParticleCollection::from(particles);

given that our collections also model a std::input_range, it's also possible to construct from them using this approach.

Open questions currently are:

• Does this go into the right direction for your use case?
• Currently ranges of mutable handles will yield "standard" collections, while ranges of immutable handles will yield subset collections. There is currently no way to change this, and trying to do so will yield an invalid_argument exception. Is this a problem?

[m-fila]

If we go this way then (later) we might also want to add customization point for std::ranges::to from C++23 to work with collections. Since collections are ranges, then std::ranges::to should look either for constructor taking range or constructor with std::from_range_t (disambiguation) and then range. I'd be against going with just range, since it's too easy to use by mistake especially there that subtlety subset/mutability (and we already delete copy constructor). But the constructor with std::from_range_t should be fine.

[tmadlener]

Since collections are ranges, then std::ranges::to should look either for constructor taking range or constructor with std::from_range_t (disambiguation) and then range. I'd be against going with just range, since it's too easy to use by mistake especially there that subtlety subset/mutability (and we already delete copy constructor).

Good point. I agree with not having a constructor simply taking a range. Should we already now add that constructor and hide it behind #if defined(__cpp_lib_containers_ranges) in case we decide to go forward with this approach here?

[m-fila]

Good point. I agree with not having a constructor simply taking a range. Should we already now add that constructor and hide it behind #if defined(__cpp_lib_containers_ranges) in case we decide to go forward with this approach here?

Yes, let's do that

[tmadlener]

Added the constructors with the std::from_ranges_t tag and some tests.

[m-fila]

LGTM

[wdconinc]

I'm sorry I haven't really had a chance to engage with this PR in the past weeks. Looks good though, but haven't tested.