integrate con4m v2

[ee7]

con4m was rewritten with v2, most importantly to:

• Decrease the chalk startup time
• Supported multi-threaded attribute access

Current flow

Currently, building chalk execs the con4m executable to generate c4autoconf.nim for Nim-native data structures and getter procs:

chalk/chalk.nimble

Lines 54 to 60 in 4157b58

	if [ ! ${OUTFILE} -nt ${SPEC} ] ; then
	echo Config schema changed. Regenerating c4autoconf.nim.
	con4m gen ${SPEC} --language=nim --output-file=${OUTFILE}
	else
	echo No change to chalk.c42spec
	fi
	""")

Then running chalk:

1. Runs con4m code to load and validate the chalk config (which doesn't change)
2. Uses that environment to load and validate the built-in configs
3. Uses that environment to load and validate any user-supplied config

This also involves flushing the con4m attribute state to the Nim-native data structures a few times, so it stays synced.

Future flow

con4m v2 allows chalk to save and restore runtime state by embedding an object file into the chalk binary, such that chalk can perform only the necessary work that would change per-invocation (like user-supplied config). This should reduce complexity overall in configuration loading - there's no more stacking.

That is, with con4m v2, building chalk should:

1. Run the chalk configuration, generating an object file
2. Embed that object file into chalk

Then running chalk should:

1. Restore the state from the object file
2. Partially process the command-line to find external configs
3. Process those external configs
4. Perform the requested operations

Eventually we may want to allow pre-compiling user-configs for later runs, but that introduces significant complexity for much less important gains.

There are also breaking changes in the language.

Refs: #26
Refs: #214