Fix expression source file in GetFirstTerm

[jodavies]

During preprocessing, RevertScratch has not yet been called in the current module execution. So the expressions are sitting in the outfile of the previous module.

Fixes #577

The final test case does not work in tform. The manual states "If the expression has only been defined in the current module and has not yet been processed (as is the case when referring to the first term in the current expression) the answer will be unspecified. This use is considered illegal, even though it does not generate an error message." so maybe it is acceptable to leave things like that?

There is a still a parform valgrind issue to resolve.

[jodavies]

The parform problem is because the worker threads are also running this code. Then *term appears to be zero in the workers, so they try to access term[-1]:
https://github.com/vermaseren/form/blob/fc829afdf051c817fb53f4d614ba6065db54f8c7/sources/pre.c#L4887

Presumably only the master thread should actually be running this?

[tueda]

Thanks for spotting this! During preprocessing (all processes are known to reach here), we can broadcast the value (the result of isnumerical(expr), in pre.c, via PF_BroadcastNumber). During runtime (firstterm_), it is more difficult; for now we could file this in a new issue.

[jodavies]

OK, then we can skip parform for this test for now.

[jodavies]

This version skips the test for parform, and also adds a test of the runtime error (use in the pre-processor of an expression defined in the current module).

[coveralls]

coverage: 50.456% (+0.1%) from 50.356%
when pulling 9f63af5 on jodavies:issue-577
into fc829af on vermaseren:master.

[tueda]

Looks fine to merge.