refactor: remove remaining chalkConfig field accesses

[ee7]

• Followed the steps in the contributor's guide: https://crashoverride.com/docs/other/contributing#filing-the-pull-request
• PR title uses semantic commit messages
• Filled out the template to a useful degree
• Updated CHANGELOG.md if necessary

Issue

#214

Description

Continue from #235, #236, and #237, removing (nearly) every remaining access of a ChalkConfig field.

With this PR, the remaining field accesses of chalkConfig are the below:

$ git log -1 --format='%h %s'
db26f26 refactor(all): avoid chalkConfig.(mark|report)Templates
$ git grep --break --heading --ignore-case 'chalkConfig\.'
src/run_management.nim
31:  get[T](chalkConfig.`@@attrscope@@`, fqn)
34:  getOpt[T](chalkConfig.`@@attrscope@@`, fqn)

Similar to previous PRs, I don't love this class of change, but we can add back some more compile-time safety around this later. The direction was to remove c4autoconf first.

Testing

Hopefully the existing tests are sufficient.

[miki725]

these sets are all kind of really ugly to follow. can we use util template or something to do the same but to make api easier to use?

Suggested change

	doAssert attrSet(keys, item & ".use", pack(true), Con4mType(kind: TypeBool)).code == errOk
	con4mAttrSet(keys, item & ".use", pack(true))

internally it can get its type from box.kind so no need to pass Con4mType directly

[ee7]

We need to specify the type so that we call the correct overload:

https://github.com/crashappsec/con4m/blob/dc5e76564d7abb962dc6519fd81f34760091b34d/files/con4m/st.nim#L378-L383

https://github.com/crashappsec/con4m/blob/dc5e76564d7abb962dc6519fd81f34760091b34d/files/con4m/st.nim#L401-L406

But all the calls will be changing here soon, and there aren't many attrSet, so I don't think it's worth adding a util template.

[miki725]

internally the util will still pass the Con4mType, but the caller of the utility will just pass a Box and it can normalize internally as necessary

[ee7]

I don't want to abstract too much here, but I've pushed 644ed8f. In particular, it'd be more confusing for me at the call site if passing three arguments causes the four-argument overload to be called internally.

We had some attrSet already, but they only acted on ConfigState (for which there is another overload). I've updated all our attrSet to use con4mAttrSet, and only implemented the necessary overloads.