glibc can be compiled such that mki-fake-dev requires /proc to works.
This on loongarch64.

Enable /proc for build vm/<target> and distro/<target> with use/stage2.
/proc needed for make-initrd >= 2.23.0.
See also https://bugzilla.altlinux.org/40900

NB: 07-kernel change breaks multi-kernel setup!

Breaks: 650e92bf

There's working use/oem to provide initial setup now too,
default root/user logins are logically conflicting with it
most of the time.

This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.

Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit.  Feel free to
provide constructive criticism :)

Some path-related bitrot has also been fixed while at that.

The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).

It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.

This also cleans up the kludge previously stuck into build-vm.

Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).

Classic VEs don't carry any kernel since these are running
under a single OpenVZ (or potentially LXC) kernel image;
ARM Multiboot (TWRP in this particular case) allows to boot
off a chroot via kexec, and we need a kernel in it for that,
obviously.

No bootloader required inside such VE though.

This subprofile is akin to THE_* variables family: the configuration
bits and script hooks sitting there influence whatever chroot is
declared to be the user facing one in the end, whether it comes
from vm image or live subprofile.

The services feature ought to be a changeset of its own which would
be based on rootfs and become the base for ve/vm changes but I chose
to just do it atomically; some pre-existing duplicates are pruned now.

A few too many downstream makefiles employed the pattern
of "export GLOBAL_VAR := $(VAR)"; macroize that.

Yes, mkimage-profiles is now able to build VM disk images.
So far the support is pretty basic:

- a single hard drive image with a single partition/FS
- only stock root password is configurable
- LILO is hardwired as a bootloader

The resulting images tend to boot under qemu/kvm though.

Please see doc/vm.txt for the warning regarding additional
privileges and setup required.  This was started back in
February but I still hoped to avoid sudo/privileged helper
(and libguestfs is almost as undistributable as can be)...

Thanks:

- http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html
- Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen
- led@, legion@, vitty@, aen@ for providing advice and inspiration

Several targets were used in a duplicated way
that made no harm but no sense either.

The features might get copy-pasted (or even copied-and-pruned)
when initialized; there's an unneccessary duplication of the
function name in the line adding it to FEATURES list, thus
prone to being forgotten and causing some havoc later on.

It was wrong in the first place but tackling this with some
double-colon rules ran into terminality issues, and further
tortures were considered unneccessary.

The current solution isn't perfect (no completely transparent
function name registration upon corresponding target being called)
but at least it is an improvement...

This is quite a large-scale change since mkimage-profiles got used to
baking distributions over the last year, and virtual environments are
quite different, so e.g. image.in/Makefile had to be split in two with
the main part of it moved into features.in/iso/lib/.

Short overview:

- features.in/Makefile: lib/ support
  (supporting VE images requires dynamic modifications
  to image.in/Makefile before starting the build;
  the most natural way to achieve that seems to use
  features mechanism along with makefile include dir)

- packaging format related part moved into features.in/pack
  (should be better prepared for diversity either)
- features.in/iso renamed to features.in/build-distro
- features.in/ve  renamed to features.in/build-ve
  + NB: these could not be merged as e.g. features.in/build
    due to completely different script hooks

- lib/image.mk renamed to lib/build.mk
- image, config, log postprocessing moved downstream
- added a sort of a topping in the form of lib/sugar.mk
- assorted style fixups (like ifeq usage)

- clean.mk: reliability fix (the problem was observed by Oleg Ivanov
  and me too but finally it did get the attention quantum)

- reviewed, updated and extended docs
  + QUICKSTART: should be[come] a step-by-step guide
    (thanks Leo-sp50 for prodiving feedback)