boot-loader-spec: undo redefinition of $BOOT

boot-loader-spec: undo redefinition of $BOOT

In 53c26db4dac0f5b79ca2a57364ee7df78a14bbfd the meaning of $BOOT was
redefined. I think that's quite problematic, since the concept is
implemented in code and interface of bootctl. Thus, I think we should
stick to the original definition, which is: "where to *place* boot menu
entries" (as opposed to "where to *read* boot menu entries from").

The aforementioned change was done to address two things afaiu:

1. it focussed on a $BOOT as the single place to put boot entries in,
   instead of mentioning that both ESP and $BOOT are expected to be
   the source

2. it mentioned the /loader/ dir (as location for boot loader resources)
   itself as part of the spec, which however only really makes sense in
   the ESP. /loader/entries/ otoh makes sense in either the ESP or
   $BOOT.

With this rework I try to address these two issues differently:

1. I intend to make clear the $BOOT is the "primary" place to put stuff
   in, and is what should be mounted to /boot/.

2. The ESP (if different from $BOOT) is listed as "secondary" source to
   read from, and is what should be mounted to /efi/. NB we now make the
   distinction between "where to put" (which is single partition) and
   "where to read from".

3. This drops any reference of the /loader/ dir witout the /entries/
   suffix. Only the full /loader/entries/ dir (and its companion file
   /loader/entries.srel) are now mentioned. Thus isolated /loader/
   directory hence becomes irrelevant in the spec, and the fact that
   sd-boot maintains some files there (and only in the ESP) is kept out
   of the spec, because it is irrelevant to other boot loaders.

4. It puts back the suggestion to mount $BOOT to /boot/ and the ESP to
   /efi/ (and suggests adding a symlink or bind mount if both are the
   same partition). Why? Because the dirs are semantically unrelated:
   it's OK and common to have and ESP but no $BOOT, hence putting ESP
   inside of a useless, non-existing "ghost" dir /boot/ makes little
   sense. More importantly though, because these partitions are
   typically backed by VFAT we want to maintain them as an autofs, with
   a short idle delay, so that the file systems are unmounted (and thus
   fully clean) at almost all times. This doesn't work if they are
   nested within each other, as the establishment of the inner autofs
   would pin the outer one, making the excercise useless. Now I don't
   think the spec should mention autofs (since that is an implementation
   detail), but it should arrange things so that this specific, very
   efficient, safe and robust implementation can be implemented.

The net result should be easy from an OS perspective:

1. *Put* boot loader entries in /boot/, always.

2. *Read* boot loader entries from both /boot/ and /efi/ -- if these are distinct.

3. The only things we define in the spec are /loader/entries/*.conf and
   /EFI/Linux/*.efi in these two partitions (well, and the companion
   file /loader/entries.srel

4. /efi/ and /boot/ because not nested can be autofs.

5. bootctl code and interface (in particular --esp-path= and
   --boot-path=) match the spec again. `bootctl -x` and `bootctl -p`
   will now print the path to $BOOT and ESP again, matching the concepts
   in the spec again.

From the sd-boot perspective things are equally easy:

1. Read boot enrties from ESP and XBOOTLDR.

2. Maintain boot loader config/other resources in ESP only.

And that's it.

Fixes: #24247