This replaces two raises of `ParseError` by `ConfigError`, which makes
it so we get the desired exit code when `ui.detailed-exit-code` is
enabled. Because the exceptions include a location, I had to add that
to `ConfigError` as well. I considered making `ConfigError` a subclass
of `ParseError`, but it doesn't feel like it quite passes the "is-a"
test.

I used "config error: " as prefix for these errors instead of the
previous "hg: parse error: ", which seems a little less accurate now
(and, as I've said before, I don't know what the "hg: " part is
supposed to signify anyway). I can easily be convinced to change the
prefix to something else (including "abort: ").

Some of the exceptions raised here mean that we fail to even load the
`ui` object in the `dispatch` module. When that happens, we don't know
to use detailed exit codes, so some tests (e.g. `test-hgrc.t`) still
see exit code 255. I'll try to get back to that later. It should be
possible to give detailed exit codes if at least part of the config
can be read (e.g. when the system-wide one enables detailed exit codes
and the user's config fails to parse).

Differential Revision: https://phab.mercurial-scm.org/D9355