Users can now configure a "notification callback"; notifications are
raised when a condition occurs in a git repository that an end-user
should know about, or that the calling application may wish to act on.
Notifications provide structured data, that is provided based on the
type of notification (for example, file paths).

In addition, an an informative message is provided when a notification
is raised; the structured data should be sufficient for callers to build
their own message, but the provided message should make that
unnecessary.

Some examples of likely future use of notifications:

* `core.safecrlf=warn` messages are warning-level notifications. This
  allows the calling application to receive these notifications and
  display them to the user (for example, sending them to the console).

* When a file cannot be written during checkout, we should inform the
  calling application. By default, git continues to check out when one
  (or more) paths fail to be written, but conclude that the checkout
  failed overall. Given this somewhat odd behavior, callers may wish to
  short-circuit this when any path fails to be written.

* Callers may want structured failure information for a `safe.directory`
  failure so that they can get the file path without having to try to
  "screen scrape" the git_error message.

Produce warning-level notifications when `core.safecrlf=warn`.

Produce an assertion when internally invalid CRLF configuration state
exists.

The `cl_invoke` mechanism saves the current state so that helper methods
(and callbacks) can use `cl_assert` logic, but attributing the failure
to the correct lines (at the invoke-point).

Don't just raise CRLF notifications when `core.safecrlf=warn`, also
raise notifications when `core.safecrlf=true`. The `core.safecrlf=true`
notifications are _fatal_ errors, however. These exist so that users can
get the filename that failed during a fatal error.

Provide a notification handler in the CLI so that (for example) warnings
and non-fatal error information can be sent to stdout. The CLI ignores
"fatal" level errors since they're superfluous; it will get the same
error after the function returns.