Vivado was inferring an SRL16 from a MultiReg in some cases

This tags the first register in each `MultiReg` or `ResetSynchronizer`
with the attribute `nmigen_async_ff` and then applies a false path and
max delay constraint to all registers tagged with that attribute in
the `.xdc` file.

The max delay defaults to 5 ns and has an override, `max_delay` where
it can be changed for the > whole project. It's possible to make this
an argument to `MultiReg` instead, but is more complex.  > git commit
-m "add clock domain crossing constraints on Vivado This tags the
first register in each `MultiReg` or `ResetSynchronizer` with the
attribute `nmigen_async_ff` and then applies a false path and max
delay constraint to all registers tagged with that attribute in the
`.xdc` file.

The max delay defaults to 5 ns and has an override, `max_delay` where
it can be changed for the whole project. It's possible to make this an
optional argument to `MultiReg` instead, but is more complex. It would
probably work to set `nmigen_async_ff` to the desired delay rather
than just `TRUE`. I'm not sure how hard it would be to extract that in
the TCL or if it would be easier to keep a dict of all used delay
values and put a line for each into the `.xdc` file.

…_cdc_constraints

the false path had precedence over the max_delay despite the docs

the large negative min delay effectively disables hold path timing
which was the intended goal of the false path.

MultiReg renamed to FFSynchronizer

This is effectively equivalent without the ugly constant
There is now no hold path in the timing report, but it retains
the max_delay.

error messages and comments
did not merge xilinx_7series.py