Consolidate duplicate commands, establish HERMIT.API.Prelude

[RyanGlScott]

This is my attempt at doing some slight cleanup of the command situation in hermit-shell at the moment. This pull request does the following:

• When there are two commands with the same name and number of arguments (but different argument types), it creates a typeclass to combine them. For example, lhsT :: Transform LCore String -> Transform LCore String and lhsR :: Rewrite LCore -> Rewrite LCore were combined into a single command lhs :: LHSArgs a b => Transform a b -> Transform a b (with LHSArgs LCore String and LHSArgs LCore LCore instances)
• Removes OverloadedStrings in certain parts of the API (namely, where it could confuse the newly introduced typeclasses). Things that were previously newtypes (CoreString, Name, LemmaName, etc.) are now type synonyms.
• Addresses the collision between certain Prelude functions and HERMIT commands. Both define the following: abs, any, all, fail, id, log, not, repeat, and replicate. I "fixed" this by introducing the HERMIT.API.Prelude module, which exports HERMIT.API and everything from Prelude except for those particular functions. If you want to use them, launching hermit-shell now runs import qualified Prelude as P by default.
• Changes all examples to use the above modifications

[RyanGlScott]

My concern with making the above commands fully polymorphic was allowing them to be used in places where they shouldn't be. For example, AFAICT in HERMIT, id can only be used with a RewriteT LCore or RewriteT LCoreTC, so I wanted to avoid a scenario in hermit-shell where the phantom type of Rewrite could be instantiated with a type that id wasn't meant to work with.

This might be excessively paranoid, though, since in practice most of these commands can only be used with one specific Shell combinator. I'd have to investigate to see if there are any specific ways to circumvent HERMIT's types using hermit-shell.

[xich]

The fact that id only works at those two types is considered a limitation of the current shell... allowing more things (especially the KURE combinators like id, any-td, >>>, <+, etc) to be polymorphic was (at least IMHO) a goal for the new shell.

The reason we overloaded so much in the old shell (having two lhs commands, for instance) was to mitigate this limitation that everything had to be monomorphic. Having a single polymorphic lhs would be much better!

So, I agree that the type class approach here matches the behavior of the old shell more accurately, which may be a thing you want right now as you test things, but that old behavior was not itself ideal.

[RyanGlScott]

Oh, that's definitely a compelling argument, then. I'll go ahead and purge those typeclasses.

[RyanGlScott]

Closing stale PR.