hgmain: enable chg

Summary:
Re-enable chg since chg can now run native Rust commands.

In the new state, the dispatch logic tries things in this order:

    - chg (both Python and Rust commands)
      - bindings.commands.run
        - hgcommands::run_command
          - clidispatch (Rust commands)
          - HgPython (Python commands)
            - edenscm.mercurial.entrypoint
              - dispatch.py:run
    - hgcommands (both Rust and Python commands)
      - clidispatch (...)
      - HgPython (...)

Before this stack (D16866461), the old order is:

    - hgcommands (Rust commands only)
      - clidispatch (Rust commands)
    - chg (Python commands only)
      - dispatch.py
    - dispatch.py (Python commands only)

The old order enforces `hgcommands` to not handle Python commands, because of
the undesirable Python startup time overhead comparing to chg. That is bad for
code path unification.

The new approach adds small (5ms) overhead for chg running native commands, but
it helps code unification (hgcommands take care of both Rust and Python), and
perserves the chg perf win.

Code unfication can be pushed further by making clidispatch aware of Python
commands, and move more of dispatch.py to the Rust clidispatch or hgcommands
crate.

Reviewed By: singhsrb

Differential Revision: D16866469

fbshipit-source-id: 79681cb748bd16f200424b6e30ef42aa3111d1bf

exec/hgmain/src/main.rs

@@ -35,10 +35,12 @@ fn main() {
         }
     }
 
+    #[cfg(feature = "with_chg")]
+    maybe_call_chg();
+
     #[cfg(windows)]
     disable_standard_handle_inheritability().unwrap();
 
-    // FIXME: Restore the use of chg
     let mut io = clidispatch::io::IO::stdio();
     let code = hgcommands::run_command(full_args, &mut io);
     std::process::exit(code as i32);