WIP: zshrc changes

I started expanding on the zshrc skeleton Daniel wrote, and i realised like an hour into it that the ratio of comments to actual configuration code was like 7:1 (in fact almost all of my changes are comments). I wanted to start an MR with what i have now to get feedback on whether this is a good direction to take. Is this too much documentation? I'm pretty happy with it in terms of informativeness, but i'm almost writing a secondary user guide here, and i'm not sure anyone wants to read a wall of text when they open their zshrc.

General thoughts:

• All the other start-up/shut-down files are here in the repo, but i don't think we should have the wizard install anything besides .zshrc. The other files are superfluous for most people, and creating only .zshrc allows them to simply delete that one file if they want to run the wizard again.

• We'll have to keep in mind that some packagers have their own global zshrcs that this file may clobber. I was tempted to copy my sudo command-path style into the file, until i realised that the only reason i have that style configured is so i can undo Debian's defaults...

• We also need to consider how this interacts with the existing 'recommended' mechanism as used by Debian, if at all. I had envisioned making our 'sensible' config like the most prominent option, but is that crowding down-stream out? Should we re-use the existing mechanism? Or should it be separate, but override ours? If not, how do we explain to users that there are two recommended configurations? &c.

• Since OMZ is already a de facto 'default config' for a huge percentage of users, i definitely think we should take inspiration from their settings. Obviously we don't need to copy all of it (just what's 'sensible') but i suppose that should be at least partially guided by what's become most familiar to people.

Justifications for settings changes i made (and some i didn't yet):

• HISTFILE — ~/.zsh_history seems like the most common path by far. We can't use paths containing directories that might not exist unless we use conditions or fall-backs.

• hist_ignore_space — bash and OMZ do this, so i think many people expect it.

• extended_history — OMZ does this, and i don't think there's any down side to it.

• hist_ignore_dups — OMZ does this.

• inc_append_history (or inc_append_history_time) — OMZ does this, and i think it's very useful, but i suppose it might cause problems on slow file systems or something? If we do add this, we should increase SAVEHIST to at least 5000.

• interactive_comments — bash and OMZ do this.

• bindkey -e — bash, OMZ, and Debian do this.

• matcher-list — OMZ is case-insensitive by default, and it's common to make bash work that way too. However, i know some people feel strongly about this. I personally use a 'smart case'-like setting where lower-case letters are treated case-insensitively and upper-case letters (preferably) aren't, and i thought that might make a good general compromise. I also added partial matching around [._-], but maybe that's pushing it; OMZ doesn't even do that.

• ignored-patterns — I don't think OMZ does this, but i don't find it useful to complete _-functions unless specifically requested. There are several commands, like which, where this can be incredibly irritating, especially if you use _approximate. My only fear is that someone might set completers so that _ignored isn't present, without realising that this will mean they can't see the custom _-prefixed functions that they insist on creating for some reason. (I would also add this to CORRECT_IGNORE if we enable correction. zsh constantly asking me if i meant _some_garbage confused me a lot when i first started using it.)

• menu select — OMZ and Debian do this.

• Bindings — As i mentioned on the ML, if we can improve the default key bindings by looking at terminfo from within the shell, i think we should do that. There doesn't seem to be any reason to do it in the config. One thing i would recommend specifically is binding kcbt (Shift+Tab) to reverse-menu-complete, which OMZ does.

• Colours — Should we? I believe Debian do this (for the prompt) for both bash and zsh. I know some people get upset about it though.