Design a highly approachable directory structure.

[Randy424]

To meet our maintainability goals it's critical that our directory structure satisfies a few requirements:

1. The structure should leverage Cypress 12's new standards for the preprocessor API (for example, by default, Cypress will execute certain code ahead of the tests. Specifically, this will be the cypress/support/e2e.js or cypress/support/component.js files). This applies to support files but also to the new config structure.

2. We should respect deprecated conventions/preprocessor APIs (plugins directory, cypress/index.js, etc.). Files that leverage older api conventions should be migrated to adopt the more recent one.

3. We must access current directory naming conventions in clc-ui-e2e, do they make sense, are they helpful? We should also consolidate helper functions, custom cypress functions, and reusable behavior in the code, where possible, and move them to the appropriate top-level directory (this should be the support directory). Let's limit the scope of this issue to the functionality required for our MVP.

[dtthuynh]

(Mostly note to self)
Consider generic JS functions vs custom commands vs custom queries:

1. https://docs.cypress.io/api/cypress-api/custom-commands#2-Dont-overcomplicate-things
2. https://docs.cypress.io/api/cypress-api/custom-queries
3. https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests

[Randy424]

Ideas:

• Test code needs to be organized more tightly. It would be nice if the code was not modularized so aggressively. When reading the current code, it becomes necessary to move 2-3 files away from the the test suites to find the selectors/assertions etc.
• Test code that is re-used across multiple suites might need their own file/module, but when they are used once, it is probably best to keep them in the test or close to the test.
• assertions should be used at the spec level, not within the helper functions, so it's always clear why something is failing.