give a hard error upon redefining a built-in command

[jyn514]

happened to notice this while working on https://github.com/martinvonz/jj/issues/2866

Checklist

If applicable:

• [x] I have updated CHANGELOG.md
• [x] I have updated the documentation (README.md, docs/, demos/)
• [x] I have updated the config schema (cli/src/config-schema.json)
• [x] I have added tests to cover my changes

[epage]

previously, aliases to built-in commands were silently ignored. this matches git's behavior, but seems unhelpful, especially if the user doesn't know that a command with that name already exists. give a hard error rather than silently ignoring it.

As another point of comparison, cargo produces a warning https://github.com/rust-lang/cargo/blob/fc1d58fd0531a57a6b942a14cdcdbcb82ece16f3/src/bin/cargo/cli.rs#L272-L276

There are other cases where we provide a warning but say we might turn it into a hard error in the future.

[jyn514]

hmm. note also that https://github.com/martinvonz/jj/pull/3015 is going to give a hard error if an alias is the wrong toml type (e.g. a number instead of a list), and it needs to do that or it can't expand the help (or at least, it would make it much harder). so it might make sense to match that behavior? but i don't feel strongly, a warning seems fine too.