Re-host and filter packages from Entware

[matteodelabre]

Current Toltec installs use a dual-source configuration: opkg fetches packages both from https://bin.entware.net/armv7sf-k3.2/ and https://toltec-dev.org/stable/. This has the advantage of saving bandwidth costs on our server, but has several drawbacks:

• Updates coming from Entware are immediately available to all users without giving us time to vet that they properly work with our packages. See for example the recent rename of wget to wget-ssl.
• Due to limitations in opkg, we can’t easily override packages from Entware (or we have to make sure that our version always has a greater version number). See for example the already existing wireguard-tools in Entware (#285). For another example, Entware already has some Qt packages (qt5-core, qt5-network, qt5-xml) that are stuck on 5.14.2 (#212).
• Packages from Entware are not listed on the Toltec website (#139).

To address those limitations, we may want to re-host packages from Entware directly on Toltec. We would be free to pin some older package versions if necessary, or filter out some packages that are known to break on reMarkable or that we wish to replace with our own.

[matteodelabre]

We may also want to rebuild Entware packages from source, for example to make sure that they match our toolchain. To avoid having to rewrite their recipes to our format, we could make our tooling support the OpenWrt recipe format (see toltec-dev/build#18).

[LinusCDE]

Wouldn't we override their packages by having our archs (rmall, rm1 and rm2) have higher priorities than theirs? Or is that rule secondary to a higher version?

[Eeems]

* Updates coming from Entware are immediately available to all users without giving us time to vet that they properly work with our packages. See for example the recent rename of `wget` to `wget-ssl`.

We could always host a snapshot of the repo for stable and update it with the normal process we use for toltec as another option.