Allow setting a prefix path for the client

[mjumbewu]

The point of this feature is to support deploying a map at a subpath instead of the root path of a domain. For example, if an organization has a new map each year, but wants all maps to be available on the same domain:

• https://sampleorg.com/ for the current year's map
• https://sampleorg.com/2024/ for last year
• https://sampleorg.com/2023/ for the previous year
• ...

This would be achieved by using a reverse proxy like nginx at https://sampleorg.com/ that routes the traffic at each path to the appropriate place.

Setup

1. Add a 'BASE_URL' value to the settings, or a BASE_URL environment variable.

Other designs considered

We could have allowed multiple maps built to pull from different datasets to be accessed from multiple paths. The flavor and dataset is currently determined globally by the SHAREABOUTS dictionary in the Django settings (frequently set by environment variables). Instead of having global settings, we could make these settings path-specific -- something like:

SHAREABOUTS = {
    ':root': {  # <-- ":root", or "default" maybe
        'FLAVOR': 'cycle3',
        'DATASET_ROOT': '...',
    },
    '2024': {
        'FLAVOR': 'cycle2',
        'DATASET_ROOT': '...',
    },
    '2023': {
        'FLAVOR': 'cycle1',
        'DATASET_ROOT': '...',
    },
}

And for backwards compatibility, if FLAVOR and DATASET_ROOT are set at the top level of the dictionary, then everything works as it currently does. This is still something that could be done in the future, and would be possible in part by the work in this PR.

There are also drawbacks to the above alternative:

• There's a higher burden of backwards-compatibility. When deploying new map versions, the cycle1 version of the site would have to be updated to work with any code changes that happen in the cycle2 and cycle3 sites (as long as all of the customization happens in the specific flavor apps that's doable).
• It doesn't necessarily solve the problem of an organization that has an existing site that they would like to deploy a Shareabouts map to at a subpath.

Needing to set up a reverse proxy in order to use this feature is introducing additional complication, but I think it is the most flexible way to achieve the feature, and puts in place concepts (like arbitrary site prefixes) that can be used in the future.