Incorrect FreeVars Type case for newtypes and enums

[RyanGlScott]

While auditing the code in Cryptol.IR.FreeVars recently, @yav and I noticed a bug in the FreeVars Type instance involving TNominal (i.e., newtypes and enums):

cryptol/src/Cryptol/IR/FreeVars.hs

Line 162 in 9821aa9

TNominal nt ts -> freeVars nt <> freeVars ts

There are two things wrong here:

1. This collects the free variables of nt (a NominalType), but the FreeVars NominalType does not return the name of the nominal type (intentionally so). As such, if you had newtype N = { x : Bit }, then freeVars N would not include N, which is a pretty serious bug.
2. Less seriously, the code here overapproximates the set of free variables by collecting all of the free variables from the definition of nt. For example, freeVars N will include Bit because the FreeVars NominalType instance includes the free variables of N's fields, even though the type N doesn't directly mention Bit.

To fix both of these issues, we should modify the instance so that it only includes ntName nt (but no other parts of nt) in the Deps that this returns.

In practice, these issues are unlikely to cause anything bad to happen within Cryptol itself. This is because the FreeVars instances are primarily used for sorting declarations in dependency order, but we only sort top-level functions, not nominal type declarations. Still, it would be good to fix this so that Cryptol API users could sort nominal type declarations in dependency order if they wanted to.