Improve performance of CreateSharedString by using std::unordered_set instead of std::set

[halbGefressen]

The current implementation of CreateSharedString uses std::set, which has logarithmic find runtime. In practice, this is very slow and infeasible if used for many strings. In contrast, std::unordered_set has an amortized constant lookup time which we found to be much faster.

I chose FNV1a because it is fast and has good collision behaviour in general. The downside is that when serializing large quantities of user-supplied strings, the map is now vulnerable to HashDoS attacks. But up until now, the map was so imperformant that supplying any large amount of strings caused a denial of service anyway, so this is clearly an upgrade. If this poses an issue nevertheless, I suggest implementing something like BLAKE3.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[thejtshow]

Just for my curiosity - the standard library provides a hash for basic string, does FNV1a provide material performance or collision improvement over the compiler provided hash functions? My initial thought would be to just wrap std::hash with the offset calculation logic to reduce the footprint of code needing maintained.