Path forward for encouraging proper context handling

[shlevy]

Once we're all wrapped up with the initial string context handling support, we need to decide what we want to do moving forward to make it less likely a context misuse can slip in. Two concrete proposals:

1. Have the core NixString manipulation functions be named in such a way as to indicate their proper use, and detailed haddocks on the functions and NixString itself to describe how things should be used.
2. Use types to represent the different cases, requiring all creation or consumption of NixStrings to go through these:
   a. newtype ContextlessString = CS Text whose FromValueraises an error if the string has context and whose ToValue just makes a string without context
   b. newtype IntentionallyIgnoredContextString = IICS Text whose FromValue ignores string context
   c. data StorePathString = SPS Text whose ToValue makes a string with singleton context from the string's value
   d. data StringWithContext = SWC Text (Set Context) to get the full access.
   We could go even further here and have something like newtype RelevanceProof a = Relevant a and type StringWithContext = (forall t . (Text, Tagged t (Set Context)) -> (a, RelevanceProof (Tagged t (Set Context)) -> NixString -> a to "require" users to actually do something with the context 😉

My gut is saying we should just do 1, but curious @jwiegley and @mightybyte 's thoughts?

[mightybyte]

I think I prefer #1 in the interest of simplicity and getting something out the door sooner. We can always do #2 later if it seems worthwhile.