[WIP] Deprecate the PodioDataSvc and friends

[tmadlener]

BEGINRELEASENOTES

• Deprecate PodioDataSvc (and k4DataSvc and FCCDataSvc) as well as the PodioInput, PodioOutput.
• Add WARNING messages at runtime to inform users about the upcoming removal.

ENDRELEASENOTES

• Includes Move the DataHandle and MetaDataHandle into the k4FWCore namespace #317
• Includes Remove unnecessary PodioDataSvc from DataHandle and harmonize constructors #321

This is the first and easy part of deprecating the PodioDataSvc (see #292). Moving to non-deprecated versions wherever possible internally still needs to be done. I think it should be possible to implement the k4FWCore::DataHandle without the need of a custom DataWrapper that relies on the PodioDataSvc. The idea is to place things going through the k4FWCore::DataHandle into the TES the same way as the IOSvc / Functional utils do. That way Functional and non Functional algorithms should integrate seamlessly.

[m-fila]

Could we also deprecate MetaDataHandle in favor of MetadataSvc (or k4FWCore::getParameter/putParameter which are resolving the services internally or maybe deprecate them later too)?

[tmadlener]

Up for discussion IMO. Technically the MetaDataHandle and the MetadataSvc/MetadataUtils serve slightly different purposes at the moment (at least partially). The MetaDataHandle has the constructor taking a DataHandle as well, so it allows to easily set "collection parameters" (which are really just parameters with a different naming convention), while for the k4FWCore::{get,put}Parameter you have to be actively aware of that naming convention, i.e. podio::collMetadataParamName)

[m-fila]

Then what is the correct approach to use collection metadata in functional algorithms? They don't have any data-handles there that could be passed to metadata-handles

[m-fila]

During meeting we discussed that collection metadata in functional algorithms is a separate issue. We won't deprecate the metadata-handles here.

[tmadlener]

Strategic question: How do we want to do the phaseout here? Until we fully remove the PodioDataSvc, etc, builds of k4FWCore will have deprecation warnings pop up all over the place. On the other hand I don't think we can remove it in this PR as that would mean that there is no chance for people working on tagged releases to realize that this is even deprecated and will be removed.

Some of the warnings in k4FWCore builds could probably be fixed with some pre-processor toggling of -Wdeprecated-declaration, but I am not sure it's possible for all, nor whether we actually want to do that.