Yosys accepts non standard delay specification

[dwRchyngqxs]

Feature Description

Issue #2565 fixed by PR #2566 since commit dcd9f0a is wrong about what the standard says.
Even if it's not a problem in itself, the "bug" shouldn't have been fixed and the change could be reverted in some places without complexifying the parser. Also some tests use and target that non-standard feature but they shouldn't.

The confusion made in issue #2565 is understandable, delay3 in section A.2.2.3 of the Verilog and SystemVerilog standards are allowed in continuous assignments as module items but they are not allowed in this position in procedural continuous assignments (so as statements) and the standard provides no interpretation for what such a delay expression is supposed to mean.
The standard states:
procedural_continuous_assignments ::= assign variable_assignment | ...
variable_assignment ::= variable_lvalue = expression

Delays after always statements don't allow delay3 even though yosys accepts it:
always_construct ::= always statement (Verilog A.6.2)
always_construct ::= always_keyword statement (SystemVerilog A.6.2)
and the grammar rules that allows to put a delay after an always look like statement -> statement_item (SystemVerilog only) -> procedural_timing_control_statement -> procedural_timing_control -> delay_control
The standard states (Verilog/SystemVerilog A.6.5):

delay_control ::=
    # delay_value
  | # ( mintypmax_expression )

for reference here is delay_value:

delay_value ::=
    unsigned_number
  | real_number
  | identifier

(Verilog)

delay_value ::=
    unsigned_number
  | real_number
  | ps_identifier
  | time_literal
  | 1step

(SystemVerilog)
delay3 is not possible in this position.

Same grammar rules apply for delays before behavioral statements.
delay3 are also accepted after blocking and non-blocking assignments but they shouldn't. The grammar rule applied to end up to a delay are delay_or_event_control -> delay_control.