[EASI-3082] CRA -> Vite migration

[aterstriep]

EASI-3082

Changes and Description

• Migrated from CRA to Vite
  • Env variables are now accessed with import.env instead of process.env
• Migrated unit test runner from Jest to Vitest
  • The only real change to how we write our unit tests is using vi.mock, vi.fn, etc instead of jest.fn
  • Mocking the Okta sign-in widget is not supported in Vite, so these tests were removed since it's already covered in our e2e tests (Tests that use a canvas don't support threads in Vitest, so we removed the test in favor of being able to run the tests in a threaded environment for the sake of runtime)
  • Snapshots - updates were mostly small text and format changes (Ex: "Jest snapshot" text to "Vitest snapshot")
• Updated dependencies to get rid of errors during migration:
  • Apollo
  • Cypress
  • Storybook
  • React-csv

Other Changes

• Modified import statements for some vendor CSS styles to import using non-relative (node_modules) paths. A notable change is in https://github.com/CMSgov/easi-app/blob/1430664e318f3a875c9c30c5cffccb7c2a9fa32c/src/index.scss, where the import statement for okta-signin-widget was changed.
• Cypress was NOT updated to use Vite for preprocessing, and still uses webpack. There were issues trying to get Cypress to work with Vite using cypress-vite

Note: Running unit tests with threads turned off currently causes some tests to fail (bug explanation here)

How to test this change

• Build app locally and make sure everything works as expected
• Run unit tests
• Run e2e tests

PR Author Review Checklist

• Met the ticket's acceptance criteria, or will meet them in a subsequent PR.
• Added or updated tests for backend resolvers or other functions as needed.
• Added or updated client tests for new components, parent components, functions, or e2e tests as necessary.
• Tested user-facing changes with voice-over and the rotor menu

PR Reviewer Guidelines

• It's best to pull the branch locally and test it, rather than just looking at the code online!
• Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.
• Always make comments, even if it's minor, or if you don't understand why something was done.