Inconsistent use of strings and string_view in Categories

[wdconinc]

There is a bit of an inconsistency on how one works with Categories on Frames:

• getAvailableCategories returns std::vector<std::string_view>:

  podio/include/podio/Reader.h

  Line 32 in 2c2a0f5

  virtual std::vector<std::string_view> getAvailableCategories() const = 0;

• but then readFrame and getEntries on the category requires a string anyway:

  podio/include/podio/Reader.h

  Lines 27 to 29 in 2c2a0f5

  	virtual podio::Frame readFrame(const std::string& name, size_t index,
  	const std::vector<std::string>& collsToRead) = 0;
  	virtual size_t getEntries(const std::string& name) const = 0;

We're not clear on what the motivation for this choice is, but it forces us to do an explicit conversion where we feel we could just as well continue using string_view:

    for (const auto& _category : podio_source->getAvailableCategories()) {
      std::string category = _category;
      std::size_t n = podio_source->getEntries(category);
    }

[tmadlener]

I think part of it (at least a some point in time) was that having a std::unordered_map<std::string, V> did not have "transparent hashing" for string_view and we have a few of such maps internally that actually own the strings for which we return a string_view.

I would have to check whether this is still an issue and / or whether we can work around it if necessary. I do agree, that this should be more consistent.

[jmcarcell]

Fixed with #946.