windows: define normcase spec and fallback These will be used in upcoming patches to efficiently create a dirstate foldmap.

encoding.upper: factor out fallback code This will be used as the fallback function on Windows.

cygwin: define normcase spec and fallback These will be used in upcoming patches to efficiently create a dirstate foldmap. The Cygwin normcase behavior is more complicated than just a simple lowercasing or uppercasing. That's why we specify 'other'.

darwin: define normcase spec and fallback These will be used in upcoming patches to efficiently create a dirstate foldmap.

posix: define normcase spec and fallback These will be used in upcoming patches to efficiently create a dirstate foldmap.

encoding: define an enum that specifies what normcase does to ASCII strings For C code we don't want to pay the cost of calling into a Python function for the common case of ASCII filenames. However, while on most POSIX platforms we normalize filenames by lowercasing them, on Windows we uppercase them. We define an enum here indicating the direction that filenames should be normalized as. Some platforms (notably Cygwin) have more complicated normalization behavior -- we add a case for that too. In upcoming patches we'll also define a fallback function that is called if the string has non-ASCII bytes. This enum will be replicated in the C code to make foldmaps. There's unfortunately no nice way to avoid that -- we can't have encoding import parsers because of import cycles. One way might be to have parsers import encoding, but accessing Python modules from C code is just awkward. The name 'normcasespecs' was chosen to indicate that this is merely an integer that specifies a behavior, not a function. The name was pluralized since in upcoming patches we'll introduce 'normcasespec' which will be one of these values.

merge with stable

json: implement {help} template We should consider add HTML rendering of the RST into the response as a follow-up. I attempted to do this, but there was an empty array returned by the rstdoc() template function. Not sure what's going on. Will deal with it later.

json: implement {helptopics} template

json: implement {manifest} template Property naming was borrowed from `hg files -Tjson`. We omit branch because, again, representation of branches in this template is wonky.

json: implement {shortlog} and {changelog} templates These are the same dispatch function under the hood. The only difference is the default number of entries to render and the template to use. So it makes sense to use a shared template. Format for {changelistentry} is similar to {changeset}. However, there are differences to argument names and their values preventing us from (easily) using the same template. (Perhaps there is room to consolidate the templates as a follow-up.) We're currently not recording some data in {changelistentry} that exists in {changeset}. This includes the branch name. This should be added in a follow-up. For now, something is better than nothing.

help: populate template functions via docstrings We do this for revsets, template keywrods, and template filters. Now we do it for template functions as well.

templater: add consistent docstrings to functions The content of "hg help templating" is largely derived from docstrings on functions providing functionality. Template functions are the long holdout. Prepare for generating them dynamically by defining docstrings for all template functions. There are numerous ways these docs could be improved. Right now, the help output simply shows function names and arguments. So literally any accurate data is better than what is there now.

changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.