Use a list to log resolved ACRs in events

🛠 Summary of changes

Deter using the resolved ACRs directly in reporting. The resolved list of ACRs (or Vectors of Trust) is volatile and subject to relatively frequent change as service features are added, removed, or modified over time. Instead, most analytics users should use the resolved attribute flags (e.g., facial_match or enhanced_ipp) for event filtering. Going forward, the purpose of the sp_request.component_values field should be solely to support investigating unexpected behavior.
Eliminate unexpected "reformatting" or "truncation" of resolved ACR names. While truncating these strings makes composing queries simpler, it introduces complexity and confusion when triaging and debugging requests. Originally, the purpose was to be able to do simple filters like properties.sp_request.component_values.Pb, but with the deprecation of the VoT interfaces (and thereby the 2-character string names), the filter becomes sp_request.component_values.`urn:acr.login.gov:verified`, which is much less legible than: 'urn:acr.login.gov:verified' IN sp_request.component_values
Why not store component values as a string? Basically, VoT/vtr style components and ACR style components "stringify" differently, which would make query composition even more complex, instead of less.

Adds an array of strings containing the ACR name will be stored in sp_request.component_names.
No other changes have been made to structure of sp_request.
New specs have been added for all IAL ACRs.

changelog: Internal, Analytics, Streamlining inclusion of resolved ACR names

[ ] Create an account via the sample app
- Note: Make sure to test with both an IdV enabled and disabled SP
[ ] Check the events.log (locally or in Cloudwatch) and verify that components_values is displaying as an array
[ ] Repeat steps 1-2 for auth-only user, verified user, a verified user that has been proofed with selfie (facial match).
- Note: Pay special attention when going through the "facial match preferred" flow.

This will require updating Cloudwatch queries. Impacted ones are listed in the linked ticket.