Allow scripts to tag themselves with which DF version they have been tested with

[myk002]

When the next version of DF comes out, no script, internal or external, is guaranteed to still work. We can support some metadata in the script that indicates whether it is likely to work with the indicated DF versions. Scripts that do not specify the relevant metadata would function as they do today (that is, with nothing blocking them or warning about them)

A benefit of this is that we can hide unverified scripts from the dfhack ls command, and attempting to run them could be met with an appropriate error message like "This script has not been verified to work with Dwarf Fortress <VERSION>. If you want to try running it anyway, please use the unverified command". unverified would just run the script without the metadata check. require or reqscript would never be blocked, since it's the top-level script that would carry the relevant metadata.

This way, we can incrementally included more scripts in our releases as they are verified, and in the meantime we won't need to remove them from the distribution. This will give us some flexibility in when we do our initial releases after a new DF version comes out.

The metadata could appear like our current module or enable markers. e.g.:

--@ df_version = 0.47.05

or

--@ df_version_min = 0.47.02
--@ df_version_max = 0.47.05

with the second form more attractive to use by scripts outside of the DFHack repo that can be run with multiple DF versions. External scripts might choose to be version locked if the authors know that the code is sensitive to version changes. Do we need an additional format of comma separated list of specific versions?

[warmist]

Imho it's enough to not list on ls and warn when running. No need for another command (and it will be annoying as most scripts will not be updated each version).

[lethosor]

I think that would be fine too, although the unverified command could still be helpful to bypass the warning