In some cases a string reference is needed (e.g. when checking if a string is in a map) or a null-terminated string is needed (e.g. when calling C APIs), so a const std::string& makes more sense, but otherwise it can mean an unnecessary copy of the string to create a std::string if the caller doesn't already have one.

I noticed this recently when writing the C++ wrapper for libloot-rs as its CXX wrapper returns many strings using its own equivalent of std::string_view, so I was having to create copies of the strings just to pass them into functions where they may just be read or may be copied again.

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::NameMatches()
• SelectMessageContent()
• DatabaseInterface::GetGroupsPath()
• DatabaseInterface::GetPluginMetadata()
• DatabaseInterface::GetPluginUserMetadata()
• DatabaseInterface::DiscardPluginUserMetadata()
• GameInterface::GetPlugin()
• GameInterface::IsPluginActive()

Since there's an implicit conversion for std::string to std::string_view, this shouldn't require any consumer changes. It is a breaking change though.