dispatch: add support for the `--config-file` global option Previously, loading a one-off config file for a command could be tricky- only the system level `*.rc` file processing supported scanning a directory of files (and the current user may not have the permission to modify those directories). Setting `HGRCPATH=...` worked, but also disabled the normal processing of all system level and user level config files, and there was no way to add the normal path processing into `HGRCPATH`. Therefore, there was no easy way to append a config file to the normally processed config. Some programs have taken to rewriting config into the repo level hgrc, and removing it when they're done. This makes that hack unnecessary. Some config options (like `[auth]`) shouldn't be passed on the command line for security reasons, so the existing `--config` isn't sufficient. The config items here are handled very similarly to `--config` items, namely any item supercedes the same item in the system, user, and repo the configs. The files are processed in the order they were specified, and any `--config` item will override an item in one of these files, regardless of the order they were specified on the command line. I don't like having to disable `ui.detailed-exit-code` in `test-config.t` to appease chg, but since the (bad?) behavior also occurs with `--config`, whatever is going on was existing behavior and not a problem with this change in particular. I don't see an obvious reason for this behavior difference, and don't want to hold this up for something that nobody seems to have complained about. Also note that when there are certain parsing errors (e.g. `hg --confi "foo.bar=baz"` in `test-globalopts.t` tripped this), the code still plows through where `_parse_config_files()` is called in `dispatch.py`, but `cmdargs` isn't initialized. I'd expect a failure like that to bail out earlier, but just avoid the problem by using `pycompat.sysargv`.