Allow named configurations to be specified via the CONFIG=... build
parameter.  For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:

  - config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)

  - config/<header>.h

  - config/<name>/<header>.h (only if the directory config/<name> exists)

  - config/local/<header>.h (autocreated if necessary)

  - config/local/<name>/<header>.h (autocreated if necessary)

This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.

The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.

Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration.  This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.

Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Allow memory map entries to be read using the syntax

  ${memmap/<region>.<properties>.<scale>}

where <region> is the index of the memory region, <properties> is a
bitmask where bit 0 represents the start address and bit 1 represents
the length (allowing the end address to be encoded by having both bits
0 and 1 set), and <scale> is the number of bits by which to shift the
result.

This allows for several values of interest to be encoded.  For
example:

  ${memmap/<region>.1.0:hexraw}   # 64-bit start address of <region>
  ${memmap/<region>.2.0:hexraw}   # 64-bit length of <region>, in bytes
  ${memmap/<region>.3.0:hexraw}   # 64-bit end address of <region>
  ${memmap/<region>.2.10:int32}   # Length of <region>, in kB
  ${memmap/<region>.2.20:int32}   # Length of <region>, in MB

The numeric encoding is slightly more sophisticated than described
here, allowing a single encoding to cover multiple regions.  (See the
source code for details.)  The primary use case for this feature is to
provide the total system memory size (in MB) via the "memsize"
predefined setting.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Allow CPUID values to be read using the syntax

  ${cpuid/<register>.<function>}

For example, ${cpuid/2.0x80000001} will give the value of %ecx after
calling CPUID with %eax=0x80000001.  Values for <register> are encoded
as %eax=0, %ebx=1, %ecx=2, %edx=3.

The numeric encoding is more sophisticated than described above,
allowing for settings such as the CPU model (obtained by calling CPUID
with %eax=0x80000002-0x80000004 inclusive and concatenating the values
returned in %eax:%ebx:%ecx:%edx).  See the source code for details.

The "cpuvendor" and "cpumodel" settings provide easy access to these
more complex CPUID settings.

This functionality is intended to complement the "cpuid" command,
which allows for testing individual CPUID feature bits.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Allow values to be read from PCI configuration space using the syntax

  ${pci/<busdevfn>.<offset>.<length>}

where <busdevfn> is the bus:dev.fn address of the PCI device
(expressed as a single integer, as returned by ${net0/busloc}),
<offset> is the offset within PCI configuration space, and <length> is
the length within PCI configuration space.

Values are returned in reverse byte order, since PCI configuration
space is little-endian by definition.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Move VMWARE_SETTINGS build configuration option from config/sideband.h
to a new config/settings.h.

Existing instances of config/local/sideband.h will not be affected,
since config.c still #includes config/sideband.h.

Signed-off-by: Michael Brown <mcb30@ipxe.org>