WIP: rename chroot stage to livefs
the chroot_* scripts are a mix of those that are a part of the 'chroot' stage (the purpose of which is to build the live-OS filesystem), and those that are helpers for tweaking a chroot environment for build use (and thus are executed in 'install' mode and then later reversed after the chroot has been used).
this is very confusing for users new to the codebase, for users getting to grips with executing individual stages if they ever do, and unhelpful for even users experience with the codebase like myself as i work on it.
it is confusing enough that the man pages even have to discuss it to try to alleviate this somewhat.
this MR renames those that are a part of the 'chroot' stage to livefs_*.
the chroot script is left in place (in addition to livefs) to act as a backwards compatible redirect to livefs, just in case people are executing the major build stages directly (or following published instructions that do such). similarly the respective man page entry is left in place to helpfully point out that this major stage has been renamed. redirects are not left for all of the 'chroot' stage subcomponents.
a small commit first fixing dates and version numbers in the manpages is bundled.
edit: yes, i did test this!
a second commit also made back in 2015 but not provided here renames the associated config file from 'chroot' to 'livefs'. I have not provided this here as there is an issue I have identified regarding backwards compatibility and lb clean. lb clean does not purge the config; not unless done indirectly by a user's auto/clean script. by default there is no such file, but the one in examples includes such removal, which it does by removing each file by name. we can update that to delete both the old and new names, but we break backwards compatibility with existing auto/clean files, whereby they would no longer completely purge the config. this is a notable flaw in the design of the cleaning mechanism - not being forwards thinking towards changes to the set of config files. possibly the best thing that could be done is to have lb clean delete config files if it detects an auto/clean file (to best emulate the two common situations - a fresh config without an auto/clean and one where the user has made a config building upon the example one that does include it), and maybe provide a --no-config option to direct it not to do so for those wanting custom auto/clean files that do not purge the config (they can add use of the option to get the same result as before).
i'm just mentioning this here for the purposes of discussion though. i'd like to get the submitted change merged and do something if anything with the config file rename separately later.