Redesign codebase prep

[robdivincenzo]

Description

This PR re-organizes the codebase to prep for redesign. The goal is to organize the "upstream" main branch without interruption of the site. At a high level, it does the following:

1. Turns network-api into a useful Django project directory named foundation_cms
   1. This is now the home base for the cms apps, settings, config code, etc. and is renamed as such.
2. Turns networkapi into a simple "namespace" directory named legacy_apps to house the legacy apps
   1. With the instance-level and settings code moved out into foundation_cms, this is simply a home for the legacy apps' code.
3. Flattens the project a layer.
   1. Moves manage.py to the root directory
      1. Simplifies all manage.py commands by no longer requiring cd into network-api to run (or appending network-api to the python command like in Heroku Scheduler (i.e. python network-api/manage.py sync_locale_trees)
   2. Surfaces the apps layer up one level
      1. Instead of having the apps in root/network-api/networkapi/app1, it will be root/foundation_cms/app1
   3. Resembles something more conventional to wagtail
4. Moves settings.py into a settings app.
   1. On the surface it does nothing yet, but we have the ability to have different settings for dev, staging, and live. Currently though, all settings.py was moved to a base.py to serve as the base settings. In the longrun, this could help us to better simplify and distribute settings for various environments, instead of having everything in one file with several conditional if statements.
   2. Also, a closer wagtail convention
5. Move front end /source/ and frontend/ (compiled files) into relevant Django project folders (foundation_cms/static/ for new files) and (foundation_cms/legacy_apps/static/ for the legacy files). This should streamline development because the static assets are closer to where developers are modifying templates, whereas there was a large separation previously. Organizing the frontend assets into a static/ directory is also a Django convention and should make more sense in general.
   1. /foundation_cms/legacy_apps/static/ is the new directory for legacy source files (formerly /source/).
   2. /foundation_cms/legacy_apps/static/compiled is the new directory for those compiled source files (formerly network-api/networkapi/frontend).
   3. The same convention will follow for redesign in /foundation_cms/static/
6. /media/ and /staticfiles/ are collected in the project root folder now, alongside manage.py.
7. Beginnings of breaking down package.json scripts into separate commands for legacy and main.
8. A lot of find and replace

Link to sample test page: https://foundation-s-tp1-1991-r-v2rggk.mofostaging.net/en/
Related PRs/issues: #

Launch Notes

1. Will need to update Heroku Scheduler path since network-api is no longer needed to run manage.py commands.
2. Will need to work with the localization string repo (https://github.com/mozilla-l10n/fomo-l10n) to re-align on directories.

Checklist

Tests

• Is the code I'm adding covered by tests?

Changes in Models:

• Did I update or add new fake data?
• Did I squash my migration?
• Are my changes backward-compatible. If not, did I schedule a deploy with the rest of the team?

Documentation:

• Is my code documented?
• Did I update the READMEs or wagtail documentation?

Merge Method
💡❗Remember to use squash merge when merging non-feature branches into main

┆Issue is synchronized with this Jira Story