Property tag extended enum

[mcr]

This patch changes PropertyTag into a two-level enum. PrimitivePropertyTag is what we had before.
PropertyTag now has an Other() which can accept any tag value that a TPM might return (such as if the TPM spec evolves).
This does not enable certify.rs example to work yet, but it does get past the property_tag 303 problem.

This might not be the best/most-idomatic way to do this. I thought that the change would require extensive amounts of patching, but it only required about 6 extra lines.
It is probably a breaking change for applications that use PropertyTag. Suggestions most welcome.

Instead of a two-level, one could merge the Other(u32) into the main enum, but that means not using FromPrimitive/ToPrimitive. So a big fat match case in each direction. That probably isn't a breaking change?!
Happy to go there... maybe there are macros to make this easier that I'm ignorant about.
(I think that a closed enum should never be used for any value that comes from an external source)

[mcr]

This is an attempt to make progress on #602

[mcr]

With this code, certify errors with:

WARNING:esys:src/tss2-esys/api/Esys_ActivateCredential.c:321:Esys_ActivateCredential_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_ActivateCredential.c:105:Esys_ActivateCredential() Esys Finish ErrorCode (0x00000a9d) 
[2025-12-18T04:15:11Z ERROR tss_esapi::context::tpm_commands::object_commands] Error when activating credential: 0x00000A9D

thread 'main' (11780) panicked at tss-esapi/examples/certify.rs:385:10:
called `Result::unwrap()` on an `Err` value: TssError(Tpm(FormatOne(TpmFormatOneResponseCode { error_number: PolicyFail, argument_number: Session(2) })))

[Superhepper]

This is interesting.

What happens if we update the enum with new items? Will that be a breaking change to the API?

[mcr]

This is interesting.

What happens if we update the enum with new items? Will that be a breaking change to the API?

Well, today, with no Other(), any update would be a breaking change if there was no _ catch-all.
After this, every match {} would have to handle Other(), or have a _.
More importantly, if there an update to a TPM firmware, then software today is likely to panic.