Add IOPlugin

A URI is a resource. To access a resource you typicaly read/write data and resources have access permissions. I don't see why this is not fundamentally IO related.
Unless you want to give the URI a completely different meaning (e.g. the resource where the code is, and not the resource the code handles)...
A really generic plugin factory involves a generic constructor. This is really hard to do with templates and a URI is not the best string-based alternative. So I'd vote for keeping the name regardless of the decision. 

Using query parameters is reasonable, and I also think that query parameters will be needed sooner or later. Changing the API is changing the scope of the task becase we agreed on doing that at the first stagem, however I think it's doable. In the client code, the biggest changes occur in brion/compartmentReport.cpp and brion/plugin/compartmentReportHDF5.cpp, in the rest it's just deleting code. The annoying part is the key-value pair parsing, which can become pretty tricky if done generic, but since this detail goes into the client plugins I think that we can simply do a string comparison for the few cases where we need it. To avoid changes in BBPSDK, I'd move the AccessMode enum back to brion and keep it in constructor of the report classes.