Support more magic methods

[philsmt]

By chance I stumbled upon weird exceptions when you try to use the in operator on a DataCollection. Due to interactions in the Python data model, the absence of a custom __contains__ causes it to try treating DataCollection as a sequence...

This PR adds proper support for __contains__ in DataCollection via a custom magic method. While at it, I also added support for the OR operator for merging (both binary and infix) and excplicitly disabled direct iteration to avoid the issue above.

Open questions:

• Should __contains__ allow train ID checks? It is somewhat weird to use, but without it we would not support everything one can pass to __getitem__
• Any other magic methods we could add? What I deliberated and rejected:
  • __eq__: somewhat straightforward to add semantically, but probably not useful outside of tests
  • __len__: which axis to use, trains or sources/keys?
  • __iter__: Rather iterate explicitly via the provided methods, and avoid weird data model interactions

[takluyver]

Should __contains__ allow train ID checks?

Good question. I lean towards no, at least for now. It's easy enough to write tid in foo.train_ids.

Any other magic methods we could add?

Let's not for the moment. I could see an argument for making DataCollection behave more like a mapping of source names to SourceData objects, i.e. supporting iter & len over source names.