Feat/allow renewal of privileges

[landonshumway-ia]

We need to allow licensees to renew privileges if their license expiration date has been updated. We still prevent them
from purchasing the same privilege if their license has not been updated since their last purchase.

As part of this change, we have updated the data model for privilege records to include a dateOfRenewal field, similar
to licenses. The sorting key for privilege and license records will now be suffixed with this 'dateOfRenewal' date stamp. So for example, supposing a privilege was purchased on 2024-11-08, this SK:

aslp#PROVIDER#privilege/ne

Will now be this tracked as this SK:

aslp#PROVIDER#privilege/ne#2024-11-08

Requirements List

• No new requirements. The change should be backwards compatible with the existing schema.

Description List

• Add logic to allow user to renew their existing privileges if their license expiration date has been updated.
• move common test resources into common python folder
• Update privilege and license sorting keys to include 'dateOfRenewal' date stamp suffix.

Testing List

• yarn test:unit:all should run without errors or warnings
• yarn serve should run without errors or warnings
• yarn build should run without errors or warnings
• For API configuration changes: CDK tests added/updated in backend/compact-connect/tests/unit/test_api.py
• Code review

Closes #295

[jusdino]

This looks great!

[landonshumway-ia]

@jlkravitz This is now ready for CSG review.

[jlkravitz]

• review the pull request to get oriented
  • read the description of the pull request, which should summarize the changes made
  • read through every task on the Scrum board that's encompassed by this pull request
  • read the description of the commits that comprise the pull request
• skim all new code, in the context of existing code, looking for problems (knowing that the vast majority of new code will be covered by tests)
• review all tests
  • methodically review all new tests for correctness, quality of naming
  • look at code coverage of tests
  • determine what code isn’t tested, review that rigorously
• review documentation to ensure that it matches changes
• provide comments on the pull request on GitHub, as necessary
  • for comments that are specific to a particular line of code, comment on those specific lines
  • for comments that are more general, attach the comment to a random line in README.md (as opposed to commenting on the pull request itself), to be able to use GitHub's ability to thread discussions on those comments

[jlkravitz]

Sorry for the delay on this one- one small question but otherwise looks good! @isabeleliassen ready to merge.