`dotnet workload clean --all` should remove all workload artifacts to help recover from bad states

## Summary

`dotnet workload clean --all` should be enhanced to remove all workload-related artifacts on disk, including workload sets json files and manifests, to help users fully recover from corrupted or bad workload states.

## Background

While working on https://github.com/dotnet/sdk/pull/52434 (fixing workload repair to handle missing manifests), I observed that it's very difficult for users to recover from certain bad workload states.

For example, say a package manager deletes a manfiest file. Then, if a user deletes the `sdk-manifests` folder manually to try to fix this, this isn't sufficient to reset workloads to a clean state—somewhere on disk, the SDK still thinks workloads are installed. Users currently have no reliable way to get back to a "blank slate" for workloads.

## Problem

`dotnet workload clean --all` does not remove all workload-related components:
- Workload sets may remain on disk
- Other artifacts that track installed workload state persist
- Users can get stuck in states where workloads appear installed but are broken

## Proposed Solution

Enhance `dotnet workload clean --all` to:
1. Remove workload sets
2. Remove all manifest-related files
3. Clear any other persisted state that tracks installed workloads
4. Effectively restore the SDK to a state as if no workloads were ever installed

This would give users a reliable escape hatch when workloads get into a bad state, rather than requiring manual hunting for files across the disk.

## Additional Context

- Related PR: https://github.com/dotnet/sdk/pull/52434 (workload repair for missing manifests)
- The `--all` flag already implies a more aggressive cleanup, so this enhancement aligns with user expectations