…ager`

`WARN_ERROR` and `WARN_ERROR_OPTIONS` were introduced _before_ we had our
`EventManager` architecture. We never moved them, because we never had a need
to. However, we're working to wrap `warn_or_error` functionality into `fire_event`.
As such, `EventManager` will need the context of `warn_error` and `warn_errror_options`.
As a secondary effect, we're eliminating some globals / module variables, which will make
our event architecture a little less complicated.

Now whenever `warn_or_error` is called, it actually just passes it through
to `fire_event`. That is, `warn_or_error` will now be deprecated, and shouldn't
be used. As `warn_or_error` optionally takes a "node", `fire_event` had to be
updated to handle this extra argument.

…rn_or_error`

Previously only `warn` events handed directly to `warn_or_error` got the
`warn_or_error` treatment. In the prior commit we moved the `warn_or_error`
handling logic to `fire_event` which meant _all_ warnings were suddenly being
handled by the `warn_or_error` logic. This is undesirable as it would break a
lot of dbt-core projects. This commit takes it a step back by only using the
`warn_or_error` logic in `fire_event` if `force_warn_or_error_handling=True` is
passed to `fire_event` (by default it is `False`). Calls to `warn_or_error` will
_automatically_ pass `True` for this parameter.

… logic

We want to move to a world where _all_ warnings are handled by the `warn_or_error`
logic that now lives in `fire_event`. However we can't by default do that as that
would break many dbt-core projects currently. That is, not all warnings in dbt-core
are fired with `warn_or_error`. Thus if a project has `--warn-error` set, some set
of warnings which weren't previously being handled by `warn_or_error` would now
be handled by `warn_or_error` if `fire_event` handled all warnings with `warn_or_error`,
which would cause errors that were previously happening. Thus by default _we don't_
handle all warnings in `fire_event` with `warn_or_error`. Instead a warning in
`fire_event` will only be handled with `warn_or_error` logic if either
1. `force_warn_or_error_handling` is passed as True
OR
2. `require_warn_or_error_handing` is set to True

(1) only happens if the event was initially sent via the old `warn_or_error` function
(2) will only happen if a corresponding project flag set in dbt-core