NFC: Add write support for the password-protected MF ultralight tag

[nekolab]

What's new

• Add write capability for password-protected MF Ultralight tags.
• Fix the check condition in mf_ultralight_poller_handler_read_tearing_flags. Support for MfUltralightFeatureSupportSingleCounter doesn't imply support for reading tearing flags, as seen in NTAG21x series.
• Revised MF Ultralight poller logic from auth => read **THEN** write to auth => read **OR** write. According to NXP specifications, NTAG commands should maintain the tag in ACTIVE or AUTHENTICATED state. However, some compatible tags deviate from this spec and accept only one read/write command in the AUTHENTICATED state. This change addresses write command failures because in the previous logic it would issued after the read commands.
• More debug logs to provide users with better NFC status insights without needing to rebuild the firmware.

Verification

Testing was conducted on an NTAG shipped with an air purifier:

• Read, unlock, and save the tag first. Modified a sector and wrote it back to the NFC tag without issues. The altered sector was correctly read in subsequent actions.
• Attempted to write with an incorrect password resulted in expected write failure.

Additional testing on devices without password protection needs reviewer's help due to limited device availability.

Checklist (For Reviewer)

• [ ] PR has description of feature/bug or link to Confluence/Jira task
• [ ] Description contains actions to verify feature/bugfix
• [ ] I've built this code, uploaded it to the device and verified feature/bugfix

[nekolab]

@gornekich Thanks for the review! I totally understand your concern. I think we can separate this PR into two parts:

1. Can we consider merging the bug fix parts first? This should include the flag correction and the read or write fix. It's not related to the password but only the logic and bug fix.
2. For the write support to password-protected card part. IMO, for the NFC app, the basic scenario would be "I dumped a card and edit the nfc file, then I want to write it back to the original card". So what if we just rename the "write" to "write back to origin", validate the UID before writing, and add a new warning screen display something like "A full card write will be performed, please make sure the password is correct or it may break your card"? The write operation only happens with the full user concentration.

Also, I totally agree if the user wants to write a single sector or tune a feature with interactive UI, it should not be done in the NFC app.

[gornekich]

Still thinking about writing to password protected cards. I need some time.