Add v0.8.x deprecation warnings for PROJECT command and auto-skip

[kmannislands]

Summary

The migration guide states that features slated for removal in v0.9.x will log a deprecation warning during the v0.8.x compatibility line. Verified against the v0.8.18 build, two of these warnings are not yet implemented:

1. PROJECT Earthfile command — an Earthfile containing PROJECT my-org/my-project parses and runs cleanly with no warning. It should log a deprecation warning in v0.8.x and become an error in v0.9.x.
2. auto-skip flags/env — --auto-skip, --no-auto-skip, --auto-skip-db-path (and EARTHLY_AUTO_SKIP*) still function silently. They should log a deprecation warning in v0.8.x and be removed in v0.9.x.

Scope

• Emit a deprecation warning when the PROJECT command is encountered while parsing an Earthfile.
• Emit a deprecation warning when any auto-skip flag or env var is used.

Related

Sibling deprecation-warning work: #507 (env-var prefix), #630 (built-in ARGs). Raised from the migration-guide review in PR #14.

Part of the v0.8.18 release.

[kmannislands]

Claude did a better read of the code then I did initially when deciding this. I found out that neither PROJECT not --auto-skip are completely dead like I initially thought.

• PROJECT and org are actually still passed to experimental secret provider when configured. I'm curious is anyone is using this. The scenario that I can imagine where this would be useful is if you want to use a single secret-provider.sh at the global level but have Earthfile for different orgs/projects that should resolve secrets differently. I can see this being quite convenient since cloud secrets are removed.

• --auto-skip alone does indeed do nothing since the backend was removed by original earthly team in v0.8.16 however there's a local database option --auto-skip-db-path that when used in combination with --auto-skip will use a local bolt db. This is very interesting to learn since auto-skip is a powerful feature. Ideally we could bring it back at some point with a proper remote implementation so maybe marking as "removed in v0.9.0" is the wrong move.

TLDR; rethinking deprecation warnings and planned removal on both of these since they do appear to already have some use in current version and could become more useful with some more attention.