Fix #700: invalidate provider cache when its config changes

[phverg]

Problem

Fixes #700.

Provider.status() only checks whether the cache directory exists on
disk. Once a core has been fetched, FuseSoC happily reuses the cached
files for every subsequent run, even if the user has since changed the
core's provider: block — most notably the version field. So flipping
version: v1.0.4-rc0 → version: v1.0.4-rc1 silently keeps building
against the rc0 sources, with the only workaround being to bump the
core's own VLNV version (which then cascades through dependents).

Solution

After a successful fetch, write a .fusesoc-provider-config.json marker
inside the cache directory containing a normalised JSON copy of the
provider config. status() reads it back on subsequent runs and flags
the cache as outofdate whenever the current config no longer matches,
which then triggers the existing clean-and-refetch path.

Caches written by older FuseSoC don't have the marker; treat those as
valid for backward compatibility (no surprise refetch on upgrade) and
let the next fetch write a fresh marker so any future drift is caught.

Test plan

• test_provider_cache_invalidates_on_config_change — confirms a
  changed version flips status from downloaded to outofdate.
• test_provider_legacy_cache_without_marker_is_valid — confirms a
  pre-marker cache is still treated as downloaded.
• Existing provider tests (test_git_provider, test_url_provider,
  test_uncachable, etc.) still pass.
• pre-commit run -a clean.

[olofk]

This makes sense, but I need to think if there are some other implications of this. About to release a new FuseSoC version, so this fix will likely land after that.