Assert that general always blocks have some timing control

[AndrewNolte]

From 9.2.2.1 General purpose always procedure:

"""
The always keyword represents a general purpose always procedure, which can be used to represent
repetitive behavior such as clock oscillators. The construct can also be used with proper timing controls to
represent combinational, latched, and sequential hardware behavior.

The general purpose always procedure, because of its looping nature, is only useful when used in
conjunction with some form of timing control. If an always procedure has no control for simulation time to
advance, it will create a simulation deadlock condition.

The following code, for example, creates a zero-delay infinite loop:
always areg = ~areg;
Providing a timing control to the preceding code creates a potentially useful description as shown in the
following:
always #half_period areg = ~areg;
"""

I've held off on updating all the failing tests because I want to get feedback on implementation first regarding where it should go:

• Parser, where it is in this pr. The diag here seems a bit a premature, but the other option I saw was to place it in block symbols. This impl only operates on syntax, and so would either do redundant checks or need to cache results.
• AnalysisManager, since technically that's correct, although this implementation is at the syntax level. It could also catch more cases with constant folding, but the major foot-guns are fairly simple as in the first example above.

[MikePopoloski]

Yeah, this needs to be further down the stack because of things like task calls:

module m;
  int i, j;
  task t;
    @* i = j;
  endtask
  
  always t();
  
  initial begin
    $monitor(i);
    #10 j = 3;
  end
endmodule

Probably it should go in the analysis pass.

[AndrewNolte]

So would that be recording timings in handleTiming(), then checking at the end if there were any? Or does the call expression visitor not enter in yet and analyze the subproc?

[MikePopoloski]

Probably in AnalyzedProcedure, if it's an always block, you want to check if there is no timing and if so, check the collected CallExpressions to see if any called subroutines have timing. The getFunctionDrivers method gets AnalyzedProcedures for the called subroutines so you can extend something off of that.

[AndrewNolte]

I couldn't reuse getFunctionDrivers() since it only looks at functions not tasks- but the method I added ended up having a lot of the same logic. Should I split that logic out to just analyze all calls, then filter functions for driver aggregation, and tasks for the timing check?