CDC rework and constraint generation

I have been looking at our CDC stuff and would like to make a few additions/changes:

BufferCC

BufferCC is not a safe primitive to use in general. It's totally fine as a basic building block and to synchronize asynchronous data, but for use in a design it:

• it does not enforce a register in the launching CD, so one can sample an intermediate state from combinatorial propagation
• we currently don't point out the possible pitfalls, i.e. that data does not stay coherent and that BufferCC can't be used for a bus in the general case.

I'd like to:

• Add a SingleBitCDC component (similar to our other ones) for 1 bit CDC.
• Add a SingleBitArrayCDC (better naming ideas are welcome) for the specific case of multiple bits that need not be coherent.
• Keep BufferCC, document its use for synchronizing async signals and as a basic building block for other CDC.

Automatic constraint generation

It's a bit of a chore currently to generate constraints for a bigger design. This is especially true when reusing library components like CDC for AXI: we have to understand the CDC to create correct constraints.
E.g. StreamCCByToggle needs to have false-paths on the valid/ready signals, and at least a max-delay constraint on the datapath.

From a discussion with @likewise I mocked this up here: https://github.com/SpinalHDL/SpinalHDL/compare/dev...andreasWallner:SpinalHDL:timing_constraints (the generation part is not yet what it needs to be, but I wanted to start a discussion on this)
We should be able to constraint everything with:

• false path (mostly for BufferCC uses)
• max delay (e.g. for multibit as in StreamCCByToggle)
• bus skew (missing in the mockup, needed e.g. for gray counters, configuration registers that are used unsynchronized)

constraints. I considered multi-cycle as well, but for our current set of CDC components there is no need.

Any feedback on these is very welcome.