rename litF -> litPG
Document lit (creates concrete strings) and litPG

Update on: Making lit depend on the backend

There's an implementation on the scope-as-backend branch.

Features:

• lit can be used to handle both old lit and litPG cases
• types that indicate backends are encoded into s scope
• using lit over litPG defers a choice which backend to use, but it generates an unsolved constraint
• using lit for basic backend-agnostic types like String, Int should still solve constraints immediately

Insights:

• the type class Lit has an additional type parameter - s - so it now depends on the scope
• the scope now additionally indicates what backend is used - it carries this information so we don't need yet another type parameter
• backend is determined based on the function used to execute a query e.g. Selda.PG.Class.query requires an argument of type FullQuery B { | i } where B = BackendPGClass