Fix asyncRam#: multiple clocks, undefineds, laziness

[DigitalBrains1]

This is a partial backport of #2006.

1. In Haskell simulation, the way read samples were produced, with
   unsafeSynchronizer, was simply wrong. It would compress and duplicate
   samples while traversing clock domains, which is not a correct model of
   how it works.

The generated HDL was fine, it only affected Haskell simulation.

2. The Haskell model of asyncRAM# treated an undefined write enable
   as an asserted enable. But an undefined value in Haskell can
   correspond to any value whatsoever in HDL, so HDL simulation might or
   might not write. With this commit, the XException of the write enable
   is written as the value in the RAM, since it could have either been
   written to or not been written to. On the next read of that address, it
   will return the XException.

This issue did not propagate to asyncRam and asyncRamPow2, since
there, the same condition also causes the write address to be undefined,
and this is properly handled by the primitive.

3. The asyncRAM# primitive was also too strict in most of its inputs.
   Combinatorially feeding the read output to the write-side inputs would
   lock up the simulation, while it is a valid circuit. This problem did
   not propagate to the asyncRam and asyncRamPow2 functions, which are
   lazy enough because the signals go through Signal's fmap and <*>.

4. Data written to memory is seqXd for efficiency.

Additionally, documentation for memory components was harmonized and
corrected.

Still TODO:

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

[alex-mckenna]

LGTM