CSS Restructure and Design System Implementation

### Purpose

The goal and purpose of this issue is to outline and discuss a large restructuring of all SCSS (and resulting CSS) used in the LifterLMS core.

This system must take into account LifterLMS core and third-party add-ons and themes.

### Notes

+ LifterLMS does not adhere to a design standard or system which means the creation of new visual elements and modules is difficult / time consuming.
+ Customization / themeing or skinning of LifterLMS elements is difficult due to these inconsistencies. We'd like to provide a simple solution for anyone who wishes LifterLMS to match their theme, brand, etc... which, ideally, requires limited coding.
+ Styles for common elements (such as buttons and form fields) are provided by LifterLMS but may also be provided by the theme. Years ago it wasn't guaranteed that frontend-styles would be provided for form elements but it's becoming much more common. I believe we will still need to provide styles for at least form elements but it's conceivable we could drop buttons entirely in favor of using wp-core button styles (intended for blocks). Possibly we could have an an opt-in stylesheet for forms and buttons that users could include as needed? Or possibly it's an opt-out that themes could declare they don't need using a theme-support declaration?
+ Colors: the default colors used on the frontend of the website should be switched to an extremely neutral palette (possibly using dark greys for primary and secondary colors and using a color like blue for the accent color (currently orange and / or pink)
+ "Elements" (pricing tables, syllabus, checkout, etc...) use inconsistent spacing, backgrounds, etc... This should be unified and we should use a single style for all "elements" we render on the frontend. This could then be easily styled by themers.
+ Defining a set of CSS variables in the document `:root` would allow themes (or custom CSS) to quickly overwrite all of our colors with a single code snippet. Providing a list of the `:root` variable list which could be added as a custom snippet (or to a theme's compatibility stylesheet) would make theme skinnig trivial.
+ Backwards / forwards compat: When making visual changes with CSS we must consider that not all decisions we make will be welcome. A "safe" implementation would change *nothing* visually but would replace hard-coded colors (and possibly spacing?) with CSS variables. This would ensure that existing custom CSS would continue working and future custom CSS would be simpler.
+ Typography: Ideally LifterLMS should never define font sizes and should instead defer to the theme. This isn't currently true and should be addressed. Changing font sizes might be a difficult change to "safely" implement
+ Spacing: Ideally all elements would adhere to a specified set of spacing rules (for margins and padding) and these rules should be easily customized with CSS variables.
+ Design "decisions" or "styles": should elements, buttons, forms, etc... have borders, backgrounds, rounded borders, etc...? This could be something adjusted with a CSS variable, something like `--llms-element-border-radius`, `--llms-element-border-width`, `--llms-element-border-style`, etc...?