Better type deprecation messages

[infinisil]

Motivation for this change

We want to deprecate option types over time, but how it's currently done, it's very hard to figure out which options actually use these deprecated types. This PR improves on this by allowing types to set a deprecationMessage, which when set, is displayed along the option that uses the type.

So with an option using types.loaOf, you now get

trace: warning: The type `types.loaOf' of option `foo.bar' defined in
  `/home/infinisil/src/nixpkgs/config.nix' is deprecated. Mixing lists with
  attribute values is no longer possible; please use `types.attrsOf` instead. See
  https://github.com/NixOS/nixpkgs/issues/1800 for the motivation.

Similar for types.string and types.optionSet. I also removed types.list completely because it's been deprecated for 7 years.

Previous PR's/commits that deprecated option types: fd803fc, #54637, #66346 (#16750), #96042 (#1800, #63103, #77189)

I also plan to deprecate more types in the future.

Ping @roberth @rycee @Profpatsch @danbst @rnhmjoj @worldofpeace @cole-h

Things done

• Checked that all the deprecated types are usable and display the deprecation message

[rnhmjoj]

👍 for removing list: it's been deprecated since I started using NixOS and only causes confusion.

I'm not sure about the message: loaOf and list have been completely removed can still be used string can still be used.

[infinisil]

I'm not sure about the message: loaOf and list have been completely removed can still be used string can still be used.

Not sure what you mean. loaOf is still there, it's just deprecated and aliased to attrsOf. string is also still there, it's also just deprecated and aliased to separatedString " ". Once they have been deprecated long enough we can remove them.

[rnhmjoj]

@infinisil I meant that the implementation of loaOf and list has been replaced with a change of semantics, while string continues to work exactly the same, except for the warning.

It was actually cole-h that noticed this in #96042

Even though types.loaOf is aliased to types.attrsOf now, I still think this counts as being removed

[infinisil]

@rnhmjoj I guess that's just because only a subset of loaOf's functionality has been deprecated (the part about lists), while string has been deprecated because it has such a tempting name when it often isn't the right type. I don't think there's a problem with this.

[infinisil]

I updated it to also print the files where the option is defined.