[prim] Refine target technology and tool switching

Right now our primitive library supports three `Impl` enums:
- `ImplGeneric`: generic models
- `ImplXilinx`: models used for the FPGA targets only
- `Impl`: ASIC technology-specific implementations

However, there are cases where the `ImplGeneric` implementation is only understood by certain tools, but not others. AST is an example for this (VCS vs Verilator). this means that `VERILATOR` or `SYNTHESIS` defines have to be placed into that code in order to make everything work. Another example are the ASIC simulation models for things like SRAMs, which we have to include depending on whether the tool looks at the synthesizable portion only or not.

It would probably be good to refine and document the technology and tool selection mechanism a bit better such that we can provide coherent guidance across the project how this should be handled. Otherwise this can lead to lengthy discussions on PRs since it is something that can often be handled in multiple ways.

This does not mean that we necessarily have to introduce new `Impl` enums - just some updated guidance when to use an `Impl` enum, and when to use preprocessor macro (and what macro for that matter) would be enough. In fact, creating another `Impl` enum for a tool for instance (like `ImplVerilator`) would conflate two dimensions (tool, technology) into one parameter, which is probably not what we want.

One possible solution could be the following:
Given the fact that each target technology usually offers a synthesizable view and a simulatable view, we could recommend a selection structure like this:
```systemverilog
if (ImplXilinx) begin
`ifdef SIMULATION
// simulation model
`else
// synthesizable code
`endif
end else if (Impl) begin
`ifdef SIMULATION
// simulation model
`else
// synthesizable code
`endif
end else begin // ImplGeneric
`ifdef SIMULATION
// simulation model
`else
// synthesizable code
`endif
end
```
the `Impl` switching would be taken care of with the current primitive selection mechanism (via primgen), whereas the `SIMULATION` switch would have to be implemented within each of the primitives.

In addition, a primitive shall always:
1) provide a generic implementation (`ImplGeneric`)
2) for each implementation, provide at least the synthesizable variant in order to enable linting and synthesis.

Note that we are already using a very similar approach for selecting the `ImplAsic` simulation models.

Let me know what you think.