Fixes `(Project.get-config "cflags")` so that it actually returns the
project's C flag field. Previously it was returning the project's
preprocessor calls.

This commit alters the project configuration compiler flag setting
behavior to allow users to override default project flags.

Flag setting commands (cflag, libflag, pkgconfigflag) now take lists of
strings as arguments. Previously, they were append-only and accepted
string arguments.

Now, to override flags, users can call:

```
(Project.get-config "cflag")
=> (...a bunch of default platform flags; "-wall" ...)
(Project.config "cflag" '("-my" "-new" "-flags"))
(Project.get-config "cflag")
=> ("-my" "-new" "-flags")
```

In order to append flags, users now need to `cons` to a `config-get`:

```
(Project.config "cflag" (cons "-new" (Project.get-config "cflag")))
```

BREAKING CHANGE: Code that relies on the previous behavior will break,
as calling these functions with non-list arguments is now an error. I
considered a softer path whereby we'd overload the current behavior to
avoid breaking existing users; however, the result would be confusing.
Passing a list would result in overriding the project field while
passing a single string would result in an append. A user might
conceivably wonder why passing a list doesn't result in a multi-append.
Ultimately I felt making a breaking change would be less confusing than
this compatibility preserving behavior down the line.

Provides convenience macros for appending flags to project flag fields
cflag, libflag, and pkgconfigflag.

Updates some project configuration calls in the Core library to follow
the new configuration behavior (pass complete flag sets and not
individual strings).

To account for the new flag setting configuration behavior.

Adds a preload eval to set the -Wnounknown-warning-option flag in clang
-- this way, when different versions don't support our default flag set,
they can still run tests. Otherwise passing an unknown flag to clang
results in a compilation error.