Add preference for manually installing packages

[DougTownsend]

This is a feature request based on the issue I submitted yesterday regarding Apio installing updates to the packages when any Apio commands are run.

My suggestion is having something like:
apio preferences auto-packages: This would be the default, and how it behaves now, where Apio checks for updates when commands are run.
apio preferences manual-packages: This would make it so packages are only installed or updated when apio packages install is run.

Motivation for this change:

1. It eliminates the possibility of changes made to packages breaking the functionality of a working Apio installation.

2. It is frustrating that sometimes when you run and Apio command, you have to sit through a 1-2 minute download, with no control or predictability of when that happens. It would be like if running any command in Linux ran apt upgrade. Sure, it is good to have software be up to date, but it is nice to have control over when that happens.

3. Allows for more stable installations. I am using Apio in a class I am teaching, and I use an autograder that sets up a docker container with my configurations. When I create the autograder, it installs Apio and Apio's packages. Then when students submit, it launches a copy of that configured container and simulates the students' modules. The way it is now, I either have to update the base container every time there is a package update, or the packages have to update every time a student submits their code, which makes the autograder take significantly longer (it is pretty slow as is). I understand that this is not the intended use case for Apio, but it works and it is easier than using the underlying tools like iverilog.

[zapta]

The auto packages mechanism was inspired by Platformio, a very popular embedded software tool set, and it makes easier for us supporting Apio users.

We need some time to figure out what is the best way to implement this feature request (e.g. a boolean flag or just increasing the TTL up to a limit). Meanwhile, can you try extending remote-config-ttl-days to let's say 90? I think that the file is propagated as is to the installation directory tree though it may be in a different directory than in github.

apio/apio/resources/config.jsonc

Line 6 in 970ab1e

"remote-config-ttl-days" : 1,

[zapta]

For the record, possible implementation of this feature

1. Add a boolean preference auto check for new packages (actual name TBD), default is auto checking enabled..
2. The preference can be viewed and set using apio preferences ...
3. If the flag is true, consider remote-config-ttl-days to be +infinity.
4. Reflect the preference value also in apio system info and apio api get-system.
5. When running an apio command that uses the packages, if the last check was more than N days ago, show a warning reminding the user to update manually.
6. Update the documentation of the preferences and packages commands.

[zapta]

One variant to the proposal is to not wait N days for the warning but to show a warning once a newer remote_config is available, e.g. by marking the cached remote config as 'dirty'.