fix: flow ?site_theme down through Studio container preview

In ~Palm and earlier, all built-in XBlock Sass was included into CMS
(and LMS) styles before being compiled. So, if a site theme was meant to
affect built-in XBlock styling, those changes would be manifested
directly in the base CMS CSS that is included into every single Studio
page. When the user provided the `?site_theme` querystring parameter,
which is intended to allow devs & admins to view Studio through a given
theme, CMS would look up the given theme and serve the corresponding
base CMS CSS, which would affect the built-in XBlocks views (as
expected).

After ~Palm, built-in XBlocks styles are handled more similarly to to
pure XBlock styles, in that they are only requested when CMS tries to
render the block. In Studio, blocks are not rendered by the original
request, but by a subsequent AJAX request to the `/container_preview`
enpoint. Thus, passing the `?site_theme` query parameter to the original
request will apply the given theme to Studio's chrome, but the theme
will _not_ apply to built-in XBlock views, whose CSS is now loaded via
async request.

To fix this, we simply pass Studio's querystring parameters (including
`?site_theme`) along to the `/container_view` AJAX request. This will
cause CMS to correctly serve the built-in XBlock CSS from the theme
specified by `?site_theme`, rather than whatever the current theme is.

Part of: #32292

cms/static/js/views/xblock.js

@@ -23,9 +23,10 @@ function($, _, ViewUtils, BaseView, XBlock, HtmlUtils) {
             var self = this,
                 view = this.view,
                 xblockInfo = this.model,
-                xblockUrl = xblockInfo.url();
+                xblockUrl = xblockInfo.url(),
+                querystring = window.location.search; // pass any querystring down to child views
             return $.ajax({
-                url: decodeURIComponent(xblockUrl) + '/' + view,
+                url: decodeURIComponent(xblockUrl) + '/' + view + querystring,
                 type: 'GET',
                 cache: false,
                 headers: {Accept: 'application/json'},

openedx/core/lib/xblock_utils/__init__.py

@@ -452,7 +452,7 @@ def xblock_resource_pkg(block):
        ProblemBlock, and most other built-in blocks currently. Handling for these
        assets does not interact with this function.
     2. The (preferred) standard XBlock runtime resource loading system, used by
-       LibrarySourdedBlock. Handling for these assets *does* interact with this
+       LibrarySourcedBlock. Handling for these assets *does* interact with this
        function.
 
     We hope to migrate to (2) eventually, tracked by:

xmodule/assets/README.rst

@@ -1,7 +1,7 @@
 xmodule/assets: edx-platform XBlock resources
 #############################################
 
-This folder exists to contain resources (ie, static assets) for the XBlocks
+This folder exists to contain resources (i.e., static assets) for the XBlocks
 defined in edx-platform.
 
 Concepts