Include the file-extension with the image-customization.lua file. This
will ease work with editors providing syntax highlighting, as they now
properly detect the file-type.

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

No legacy OpenWrt targets exist anymore which require the .config profile
name to differ from the image name.

All our targets use the OpenWrt device abstraction. Since commit
6ba58c9b17c90e41b521d796ab76e5723ee017170
("generic: force per-device RootFS") building non-device targets is not
possible anymore, so we can remove these obsolete handlers.

With the removal of ramips-rt305x, all targets come with opkg again.

site_code is evaluated early during config generation, so a site.conf
without site_code would hit this assertion that just printed 'Assertion
failed'. Add a proper error message to tell users what went wrong.

The inner assert() is removed, as it should never be hit (as site.conf
syntax will have already been validated when this script runs), and it
doesn't add anything (even without the assert, the attempt to index a
nil value would throw an error).

By passing a table instead of a single string, multiple different
extensions can be specified, each refering to a separate image file
generated by OpenWrt.

This is not supported for sysupgrade (as there can only be a single
image in the format expected by OpenWrt).

manifest_aliases only make sense for sysupgrade images.

target_config.lua and target_config_check.lua don't pass a table of
callbacks anymore, so target_config_lib.lua can by simplified by moving
all the code that was in the returned function to the toplevel.

So far, we were using a sort operation on the generated .config to
implement precedence of =y packages over =m, and =m over unset.
Unfortunately, this sort not only used for packages, but for all config
lines. This made it impossible to override settings from targets/generic
in a target config when the new setting was sorted before the generic
setting.

To fix this, track configurations by their keys, so we can properly
override config keys that were set before. Value-based precedence is
only preserved for package configuration.

The config() and try_config() calls always take key and value as
separate arguments now. Strings are quoted automatically; the values
true, nil and false map to y, m and unset for tristate options. config()
can take an optional third argument to override the error message to
display when the setting fails to apply.

All existing target configs generate the same .config with the old and the
new code. The new code is also a bit faster on targets with many devices.

The precedence of different package lists was broken since #1876,
disallowing removal of GLUON_FEATURES packages via GLUON_SITE_PACKAGES.

Including all package selections, both implicit defaults and explicit
handling in Gluon, the order of precedence is now the following:

1.  OpenWrt defaults (including target-specific defaults)
2.  Device-specific packages from OpenWrt
3.  Generic default packages (from target/generic)
4.  Target default packages (target/$(GLUON_TARGET))
5.  Removal of opkg for tiny targets
6.  Packages derived from GLUON_FEATURES + GLUON_FEATURES_$(class)
7.  GLUON_SITE_PACKAGES
8.  GLUON_SITE_PACKAGES_$(class)
9.  Device-specific packages from target/$(GLUON_TARGET)
10. Device-specific packages from GLUON_$(device)_SITE_PACKAGES

This also contains various pieces of cleanup:

- No hardcoded order of device classes for target_config.lua arguments
  anymore (in fact, the Makefile doesn't know anything about device
  classes now)
- target_conifg_lib.lua only hardcodes the fallback class for x86, no
  other occurences of specific class names
- Feature -> package list mapping is moved from Makefile to the Lua code
  as well (still implemented in Shell though)

Allows to append additional commands, for example using `||`.

When adding device classes, targets without devices such as x86 were not
handled. As site and feature packages are included on such a per-device
decision, x86 images ended up without most packages.

Include a class setting for a target and include the class-packages
target-wide when this setting is configured.

Fixes 9c523650 ("build: introduce device classes")

This commit allows to define a device-class flag in the target
definitions. This way, it is possible to distinguish between groups
of devices in the build-process in terms of package or feature
selection.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

This new build flag is mandatory for now (it may default to 0 in a future
Gluon version). It may be set to the following values:

* 0 - Do not build any images for deprecated devices.
* upgrade - Only build sysupgrade images for deprecated devices.
* full - Build both sysupgrade and factory images for deprecated devices.

"Other" images are handled like factory images, as they are also used for
the initial installation of Gluon on a device.

The old bash-based parsing code was way too complex. Replace it with Lua.