Improved Jargon in Haddock

[alex-mckenna]

Browsing through the docs for clash-prelude before I had a thought: it would be nice to pick some jargon to disambiguate the following:

• code which is translatable to HDL, but not synthesizable HDL
• code which is not translatable to HDL

To avoid bikeshedding too much on the words used I'll propose here (non-)synthesizable for talking about vendor tooling being able to synthesize generated HDL, and (non-)translatable for talking about Clash being able to generate HDL in the first place. This has some benefits:

• places where we warn about non-synthesizable code currently may refer to non-translatable code and this would tidy up the documentation for these functions
• by introducing the concept of translatable Clash in documentation we can make it clearer to users the subset of Haskell types which Clash will generate HDL for (i.e. [] is non-translatable because functions on it have no way of setting a bound for recursion unlike functions on Vec)

The obvious downside is explaining such a general term is a difficult thing to find a place for in API documentation. For other resources, like a hypothetical example-based Clash book it would be easy to introduce into the flow of the documentation.

CC @DigitalBrains1, who often has good ideas about documentation