ProgressiveProofer refactor 2/N: AAMVA

[matthinz]

🛠 Summary of changes

Continuing the work in #11420, this PR extracts proof_id_with_aamva_if_needed into AamvaPlugin. It then adds a spec for the plugin covering the following use cases:

• Remote unsupervised proofing
• In-person proofing (residential address == id address)
• In-person proofing (residential address != id address)

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Run through remote unsupervised IdV using an ID from an AAMVA state
• Run through remote unsupervised IdV using an ID from a non-AAMVA state
• Run through in-person proofing using an ID from an AAMVA state (same address as id)
• Run through in-person proofing using an ID from a non-AAMVA state (same address as id)
• Run through in-person proofing using an ID from an AAMVA state (different address than id)
• Run through in-person proofing using an ID from a non-AAMVA state (different address than id)

[matthinz]

Note that in the IPP + different addresses case, if the residential address failed verification, then instant_verify_result will have success: false and vendor_name: ResolutionCannotPass, so no AAMVA call will be made.

[n1zyy]

I have not run through the checklist you provided, and someone should before merging. But I spent a while working through the code and it looks solid.

[n1zyy]

❤️ for this descriptive name -- it makes perfectly clear why we go from "but the failure can possibly be covered by AAMVA" to "does not make an AAMVA call"

[gina-yamada]

Logic for existing code and new plugin remains the same. I manually tested IPP with AAMVA approved jurisdictions (CO) and not approved (CA) and get the outcome I'd expect. (For both cases; same address as ID, diff address as ID.)