Improve error message on missing `=` in config

[bentsherman]

Spun off from #4372. Consider the following configuration:

process {
  cpus = 2
  memory 4.GB // incorrect
}

Omitting the = in a config setting should lead to a syntax error, but instead it is interpreted as a command expression and usually leads to a non-sensical error:

ERROR ~ Unknown method invocation `memory` on _parse_closure5 type -- Did you mean?
  memoize

 -- Check '.nextflow.log' file for details

Instead it should be reported as a syntax error. This error happens often because of the different syntax for process config options and process directives.

The error is thrown from here:

nextflow/modules/nextflow/src/main/groovy/nextflow/config/ConfigParser.groovy

Lines 446 to 451 in 0bce2be

	MetaMethod mm = mc.getMetaMethod(name, args)
	if (mm) {
	result = mm.invoke(delegate, args)
	} else {
	throw new MissingMethodException(name, getClass(), args)
	}

[bentsherman]

The error message is slightly different if the argument is a closure:

process {
  memory { 4.GB }
}

ERROR ~ Unknown config attribute `process.memory` -- check config file: nextflow.config

The error is thrown from here:

nextflow/modules/nextflow/src/main/groovy/nextflow/config/ConfigBuilder.groovy

Lines 453 to 461 in 0bce2be

	final msg = "Unknown config attribute `$fqKey` -- check config file: $file".toString()
	if( showMissingVariables ) {
	emptyVariables.put(value, key)
	warnings.add(msg)
	}
	else {
	log.debug("In the following config snippet the attribute `$fqKey` is empty:\n${->config.prettyPrint().indent(' ')}")
	throw new ConfigParseException(msg)
	}

[bentsherman]

Not sure if it's possible to improve these errors without knowledge of the available config scopes, because there are some legitimate cases for command syntax, like plugins:

plugins {
  id 'nf-hello'
}

[pditommaso]

The config parsing logic it's extremely convoluted. Not sure how much space there's for improving the error message reporting. I'd suggest to focus on the new config subsystem

[bentsherman]

Closing in favor of #4744