Add reset-related convenience functions

[martijnbastiaan]

Still TODO:

• Write a changelog entry (see changelog/README.md)
• Write a changelog wrt added type families
• Check copyright notices are up to date in edited files

[DigitalBrains1]

These are definitely good to have! Let's get rid of "you need unsafeX to do this"! I'd like to do it a bit different though. Type safety is great. Amassing type constraints not so much.

[martijnbastiaan]

@DigitalBrains1 @leonschoorl I've added proposal for the new constraint aliases. I'm reasonably happy with their names and definition (keep in mind the long-term plan is to get rid of KnownDomain except for things like resetGen and clockGen). I also think these two constraints will cover almost all cases, so I don't feel like it's necessary to add constraints for ActiveEdge and friends. Lastly, I'm not super-pleased with the __N.B.__ explanations right now, please make suggestions (unless you guys think it's clear enough!).

[martijnbastiaan]

Maybe HasSynchronousReset dom / SetsSynchronousReset dom? (Not a big fan of contracting it to Sync btw, we don't do that anywhere else we don't do that in that module.)

[martijnbastiaan]

I've picked HasX in the end. It's a pattern used in the Haskell ecosystem more often, and I feel it pretty much reads as this domain has X.

[DigitalBrains1]

I'd like it if the documentation points out how users can manage these constraints efficiently. We discussed how people could create their own type synonyms in a single design with multiple clock domains like

type DesignDomain dom =
  ( HasSynchronousReset dom
  , HasDefinedInitialValues dom
  )

and then write all their domain-polymorphic functions in the design as

f ::
  DesignDomain dom =>
  Signal dom [...]

which is just as much code as KnownDomain dom, but correctly provides constraints whenever they use, say, orReset somewhere.

Suggested changes have been applied