FE optimization: lazy load page/question components; ckeditor; improve css compilation

[adi-herwana-nus]

Contains changes cherry-picked from #7889; continuation of #7928

Commits already merged: 17 / 36
Commits included in this PR: 7 / 36
Commits to reject: 1 / 36
Commits remaining: 11 / 36

CKEditor

CKEditor contributes the largest (1.26 MB) and it's bundled twice. It's probably bundled into UnauthenticatedApp even when there are no pages that renders a rich text editor because webpack doesn't know if its import has side effects, thus can't tree-shake it.

The custom build has been optimised upstream and while I'm at it, I upgraded it from v40 to v45. Essentially, I directly import the distributed bundles and CSS of the extensions directly so nothing unused is bundled. This reduced the CKEditor chunk size from 1.26 MB to 1.13 MB.

Most importantly, CKEditor is now lazy-loaded so only pages that need it will load it on demand. A skeleton will appear when the bundle loads, but I think this is an acceptable trade-off.

Route-based code-splitting

This is the root cause of our enormous loading times. Our bundle grows proportionally to the features we develop; there's no way around this. However, what we should be optimising isn't just reducing bundle sizes, rather, reducing bundle sizes on each user journey. There's no reason why a user who visits the Announcements page needs to wait 5 seconds for CKEditor or Ace chunks to also be fetched.

This PR implements lazy loading the components for all front-end routes we have in Coursemology. This is known as route-based code-splitting. This means that our bundle will be sliced into smaller chunks and when a user visits a page, they fetch only what they need. This naturally will increase our total built bundle size (in fact, this PR increased it from 12.68 MB to 13.79 MB), but this doesn't matter; what does is the amount of JavaScript transferred on each route. See Benchmarks below.

Route-based code-splitting also ensures that if we do have pages/components that are unoptimised, written poorly, or just inevitably large, other pages aren't "penalised" for this.

This results in pages having entry point chunks ranging from 3 kB to 145 kB, which is still an acceptable bundle size, compared to having to load the entire 3.35 MB AuthenticatedApp.

Lazy-loading assessment questions' answer components

SubmissionEditIndex at courses/:courseId/assessments/:assessmentId/submissions/:submissionId/edit now lazy-loads the answer components for different question types. This way, students who does only programming questions need not load the chunks for other questions' answers. This reduced the SubmissionEditIndex entry point chunk from 261.54 kB to 141.24 kB.

Stylesheets minification

This PR minimises our restricted CSS and SCSS imports with cssnano via PostCSS before they are imported and bundled to their respective JavaScript chunks. I specifically disabled CSS source maps since they aren't necessary and reduced bundle sizes by about ~300 kB.

[pchunky]

LGTM. Thanks for this! If there are any issues in production, we can always patch them later.

Saw you added the answer adapter for rubric-based response, too. Thanks!