TPM1/TPM2 DA policy exposure, tooling to trigger DA defend mode and proper gating on increment and unseal

Nobody has claimed this yet.

PR https://github.com/linuxboot/heads/pull/2117 fixes the #2068 tpm1 counter increment regression.

But testing on x230, I realized that DA policy cannot be extracted from TPM (STM) while qemu swtpm policy is too permissive.

We need tooling from tpmr.sh (bad_auth simulation, da_state to get TPM DA policy for current tries before threhold and how many attempts and end of TPM Defend triggered) to guide the user properly when this happens.

As of now, a TPM Defend lock activated can be reset by a TPM reset on both TPM1 and TPM2. But that doesn't give us insights on what causes the DA Defend, now exposes the DA policy, not permit us to play with it.

Start with the existing tpmr.sh entry points mentioned in the issue and review PR #2117 and issue #2068 for the TPM1 counter context. Investigate how bad_auth simulation and da_state could expose the TPM DA policy, current tries, attempt counts, and TPM Defend activation for both TPM1 and TPM2, including qemu swtpm behavior. Done means the tooling reports these states and increment and unseal operations are properly gated.

Written by the indexing model from the issue text.