[Pitch] Add Equatable and Hashable conformance to String views

[itaiferber]

I don't know if @shantini shares the same thoughts or concerns that I do, but a few of my own open questions from the thread that produced the GH issue:

Why don't string views (`UTF8View`, etc.), conform to `Codable`, `Hashable`, etc.?

Regarding String views/Substrings and Codable specifically, I suspect some amount of discussion and exploration will need to happen around deciding what behavior is expected regarding their encoding format — specifically, if there's a mismatch between the view type and the expected text encoding of the Codable format itself. For example, some formats might be constrained to UTF-8, so, e.g., String.UTF16View might need some indirect representation. The naive implementation for these views (enco…

Specifically, there are some questions about compatibility with various formats (what does it mean to encode a UTF-16 view into a format that only supports UTF-8 strings?) and ownership (what does it mean semantically to try to decode a String view?). I won't rehash the contents here (though there isn't much more to them) but I think there are some interesting things worth exploring here!