Take std::string_view instead of const std::string&

See #105.

Add constructor and setter overloads that take T&& parameters

E.g. if you've already got a std::string that you can move into the constructor then it's better to do that than to implicitly create a std::string_view and then to create a std::string from that view.

This impacts:

• The ConditionalMetadata constructor
• The File constructor
• The Filename constructor
• The Group constructor
• The Location constructor
• The MessageContent constructor
• The Message constructor
• The PluginCleaningData constructor
• The PluginMetadata constructor
• The Tag constructor
• The Vertex constructor
• PluginMetadata::SetGroup()
• PluginMetadata::SetLoadAfterFiles()
• PluginMetadata::SetRequirements()
• PluginMetadata::SetIncompatibilities()
• PluginMetadata::SetMessages()
• PluginMetadata::SetTags()
• PluginMetadata::SetDirtyInfo()
• PluginMetadata::SetCleanInfo()
• PluginMetadata::SetLocations()

I'm not sure if doing this would be worth it in practice: I don't think it would make a difference for libloot-rs, so it's a question of if LOOT would benefit. I don't think adding these overloads would be a breaking change, so they could be added any time.

Accept const std::vector<std::string_view>& in addition to const std::vector<std::string>&

This impacts:

• GameInterface::SortPlugins()
• GameInterface::SetLoadOrder()
• The Group constructor

The existing functions shouldn't be replaced, because if you've already got a std::vector<std::string> then you want to avoid having to create a new std::vector from that, but if you've already got a std::vector<std::string_view> then it would be good to also avoid having to create a new std::vector from that.

Again, I don't know if this is worth it, and adding the overloads wouldn't be a breaking change.