D17 should generate a hashlist and attest DLLs

[KazWolfe]

D17/Plogon should:

1. Generate a hashlist that gets shipped to the client as part of the distributed file(s).
2. Attest that hashlist for every plugin.
3. Attest all DLLs distributed with every plugin. a. Is there a way to exclude attesting DLLs that are from NuGet? b. Are there any plugins that ship >50 DLLs? The common good attestation engine is a bit annoying with limitations. c. If we're using hashlists, this may be unnecessary as we can validate the hashlist alone (and then check all hashes).

For future art, this can eventually be developed into a system to allow Dalamud to verify attestations locally. This may also require some extra metadata or featuresets to validate attestations. We may be able to do this by shipping the generated attestation bundles (and verifying the certificate to be the "public good" certificate) to avoid the network call.

To note: this proposal does not force attestations for plugins. My current thought is that Dalamud will verify an attestation if present and show that information to the user alongside providing the relevant link(s) to the plugin's build process and built commit. I can see a potential future where we add a requirement that mainline plugins be attested (as the process is transparent and requires no action from plugin devs), and provide a way for custom repo plugins to opt in to attestation requirements as well.

[KazWolfe]

Current proposal:

1. Add a hashes.json file to Plogon's output, next to the latest.zip. The hashes.json file should contain a KV of all files present in latest.zip.
2. For each directory within Plogon's output, an Action should: a. Attest ./**/*${InternalName}*.dll and ./hashes.json. b. Copy /tmp/attestation.jsonl to ./attestation.jsonl.
3. Ensure both hashes.json and attestation.jsonl get sent to PluginDistD17 as well.

It is important that each plugin get its own pass of an attestation so that every plugin gets its own clean file. TBD how to do this with GitHub Actions, however.

Attesting DLLs containing the plugin's InternalName should be considered a convenience; the actual file used for any sort of clientside validation and attestation will be hashes.json. If we can find a reasonable way to attest all non-NuGet DLLs, these can be added to the attestation list at a later date.