commitctx: move ChangingFiles creation directly inside `_process_files` As announced, we move it there. We focus on the signature change first, we will update the code afterward.

commitctx: create the ChangingFiles object directly in the various case No need to compute all data then create the object, we can create it early and directly store data in it. We start simple by moving create higher in the function, but the end goal is to eventually move the creation inside the `_process_files` function to take advantage of the object there.

commitctx: no longer make the storage and added/removed file optional The code using this variable is always using other, stricter, condition before using these value. So it is safe to always carry them along.

commitctx: directly gather p1 and p2 copies in `files` The only thing we do with the p1copies and p2copies is to pass them around, we we can gather them later and directly stored them in the `ChangingFiles` object.

commitctx: extract sidedata encoding inside its own function This part of the code is quite independent from the rest. Thank to the new ChangingFiles object, moving with the rest of the sidedata code (in metadata.py) is simple. The changelog.add method is simply passing the `files` object to the new function. It will be easy to increase/change the data we gather and encode without impacting the changelog method.

commitctx: directly pass a ChangingFiles object to changelog.add We pass the rich object to the changelog and it read the field it needs.

commitctx: return a richer object from _prepare_files Instead of returning a lot of different list, we introduce a rich object that hold all the file related information. The unique object help with data consistency and simply functions arguments and return. In the rest of this series we will increase usage of this object to simplify more code.

templater: teach template loader to use open_template() function The template loader can apparently load templates from relative paths, so I needed to add that support to `open_template()`. This takes the number of failing tests with PyOxidizer from 54 to 34. Differential Revision: https://phab.mercurial-scm.org/D8907

templater: restructure open_template() a little to prepare for relative paths I found that it was easier to add support for relative paths after this restructuring. It also made it easier to explain each case with a code comment (which I did). Differential Revision: https://phab.mercurial-scm.org/D8906

templater: add exception-raising version of open_template() I'm about to add another caller of `open_template()` (in the template loader). That caller will want to get exceptions instead of `(None, None)` if the template doesn't exist. This patch therefore changes `open_template()` to raise exceptions and adds a new `try_open_template()` that returns the `(None, None)` value. Differential Revision: https://phab.mercurial-scm.org/D8905

templater: replace Py3-only exception types by super-types available in Py2 As noted by @indygreg, `test-check-pyflakes.t` started failing on Py2 after my recent D8894, because that introduced catching of the Py3-only types `ModuleNotFoundError` and `FileNotFoundError`. Let's switch to less precise types that are also available in Py2. Differential Revision: https://phab.mercurial-scm.org/D8902

hgweb: enable reading styles from resources in frozen binaries All we need to do to read styles from resources is to pass the file-like object we get from `open_template()` on to `frommapfile()`. This takes the number of failing tests with PyOxidizer from 62 to 54. Differential Revision: https://phab.mercurial-scm.org/D8901

hgweb: rely on open_template()'s fallback to using templatedir() Differential Revision: https://phab.mercurial-scm.org/D8900

hgweb: open mapfile using templater.open_template() This will help us read templates from resources in frozen binaries. Differential Revision: https://phab.mercurial-scm.org/D8899

hgweb: simplify a constant-length list by converting to literal tuple The call to `.append()` has been unnecessary since d3dbdca92458 (hgweb: don't choke when an inexistent style is requested (issue1901), 2009-11-12). Differential Revision: https://phab.mercurial-scm.org/D8898

hgweb: remove some accesses to private member uimod._unset Differential Revision: https://phab.mercurial-scm.org/D8897

templater: try to read %include in mapfiles from resources The "show" style is an example of a style that uses an "%include" statement in its definition. This patch makes `hg log --style show` work. This takes the number of failing tests with PyOxidizer from 72 to 62. Differential Revision: https://phab.mercurial-scm.org/D8896

templater: unroll loop over mapfile directories I'll rewrite the handling of the `templatedir()` case in the next patch, so the two cases will be more different and the loop won't make as much sense. Differential Revision: https://phab.mercurial-scm.org/D8895

templater: make open_template() read from resources if in frozen binary This takes the number of failing tests with PyOxidizer from 87 to 72. Differential Revision: https://phab.mercurial-scm.org/D8894

templater: pass opened file-like object to templatespec I think I said earlier that I planned to create a special templatespec variant for built-in templates. That was true (I planned that), but I ended up (in this patch) just adding a file-like object to the `mapfile_templatespec()` variant instead. Differential Revision: https://phab.mercurial-scm.org/D8893

templater: replace templatepath() with function that also opens the file For frozen binaries, such as those created by PyOxidizer, I plan to make it so the templatespec can keep an opened file/resource to read from instead of needing a file path. Having `templatepath()` return an opened file should help with that. At this point, it's just a wasteful extra opening of mapfiles that we'll open again later. I'll update the read-side next so it reads from the file-like object without opening the file again. Differential Revision: https://phab.mercurial-scm.org/D8892

templater: start passing resource to read from into _readmapfile() This patch makes it so we pass in a file-like resource to read from instead of having `_readmapfile()` open the file. This is one more step towards making `_readmapfile()` able to read resources opened by from `importlib.resources`. We still need to pass in the mapfile path because it's used for loading dependent mapfiles from `%include` and `__base__`, and it's also used for giving the user better error messages. Besides that, one can safely call `_readmapfile()` with any file-like resource after this patch. Differential Revision: https://phab.mercurial-scm.org/D8891

templater: move stylemap() to hgweb_mod, since that's its only user `stylemap()` even has an error message that mentions "hgweb templates", so it seems that it's meant specifically for hgweb. Differential Revision: https://phab.mercurial-scm.org/D8890

hgweb: simplify staticfile() now that we always pass it a single directory I didn't realize this further simplifications enabled by D8786 until now. Differential Revision: https://phab.mercurial-scm.org/D8874

packaging: include templates with their package as key in package_data This is similar to an earlier patch in this series. It seems more correct to use `mercurial.templates.coal` etc as keys in the `package_data` dict now that those modules are packages. Differential Revision: https://phab.mercurial-scm.org/D8858

packaging: mark mercurial.templates and subdirs as packages We need these packages to be installed so PyOxidizer picks them up. Differential Revision: https://phab.mercurial-scm.org/D8855

templates: add __init__.py files to templates/ dirs This is necessary for them to be loaded with `importlib.resources`, which we want to do for PyOxidizer and similar. `importlib.resources` cannot read resources from submodules (`resources.open_binary('mercurial.templates', 'coal/map')` is not valid), so we need one `__init__.py` per directory. Differential Revision: https://phab.mercurial-scm.org/D8854

merge with stable