Improve "extension features" of GAP packages by turning them into explicit dependencies

[ThomasBreuer]

(This idea arose from a discussion with @fingolfin. Note that the Julia package manager now provides a similar mechanism.)

Currently several packages install additional features provided that other packages are known to be available later in the GAP session.
A typical example is CTblLib, which reads certain package files that depend on the availability of the Browse package:
Since one wants to be able to use CTblLib without Browse, CTblLib lists Browse only as a "suggested" package but not as a "needed" package in the dependencies in PackageInfo.g. The ReadPackage calls for the additional files are executed only if IsPackageMarkedForLoading returns true for Browse (in a sufficiently new version).

This works well if loading suggested packages is enabled and if the suggested packages are available at the time when the IsPackageMarkedForLoading calls are executed.
It does not work well if one starts a GAP session, loads certain packages, and then installs more packages.
It does not work well if one starts a GAP session without packages and then loads some packages by hand.
With the current setup, if CTblLib has been loaded in a situation when Browse was not available then the Browse dependent code will never become available in the GAP session, also if one (installs and) loads Browse later during the session.

We could improve this situation by extending the dependencies in PackageInfo.g by a new list Extensions; in a simple form, each entry could have the format [ <packagename>, <version>, <filename> ], meaning that the file (relative to the package directory) shall read as soon as the package <packagename> has been loaded in version (at least) <version>.

In the above example, the file of CTblLib would consist of ReadPackage calls for the Browse dependent code.
The function LoadPackage would get modified as follows:
When LoadPackage has loaded CTblLib, the Extensions list of CTblLib's PackageInfo.g (together with the information to which package the extension belongs) gets appended to a global list of pending extensions of packages, and then this whole list gets evaluated --whenever the condition of an entry is satisfied, the file in question gets read, and the entry gets removed from the list.
If Browse gets loaded via LoadPackage after CTblLib has been loaded, this LoadPackage call will find the list entry that has been added when CTblLib was loaded, and trigger that the extension becomes available.
(Thinking about pending extensions in saved workspaces, one does not want to replace the given relative filenames by absolute ones before actually reading these files.)

Perhaps this approach is too simpleminded.

• One can think about more involved conditions: Some feature may depend on more than one other package, then one could store lists of package specifications.
• I do not know whether it is necessary or desirable to deal with (cyclic?) dependencies between such extensions, for example concerning the order in which two extensions from different packages have to be loaded.

Does this idea sound reasonable?
If yes then the mechanism sketched above would not be difficult to implement.
Essentially, we have to support the new component in the Dependencies section of PackageInfo.g files, and to extend LoadPackage. Afterwards packages can start using this feature.

[fingolfin]

This is closely related to my issue #4834; the idea described here is more declarative, which I like, as it makes it easier to write code that uses the declarative information to make decisions on the meta level. E.g. to add a mechanism for controlling the order in which extensions are loaded...

One idea for that (order of loading extensions; but also mutually dependent extensions) would be to treat extension as kind of fake extra packages: i.e., give them a name (could be optional), and then allow using those names in dependencies (instead of package names). That way, one could simply let one extension depend on another...

But in practice, I really hope we won't need that; for me a major motivation in pursuing this kind of feature is precisely to get rid of circular dependencies...

[ThomasBreuer]

I think that #5375 was sufficient for regarding this issues as resolved.