fix: location_ids and buildingCatalogue are inconsistent

[KevinWu098]

Continuing the saga from #784 and #779, location_ids and buildingCatalogue are inconsistent.

Noted in #855:

Not all locations are recognized for custom events on the map even though they are for classes (BS3, for example) and some don't even read on the calendar

In the particular case above,

buildingCatalogue:

    83057: {
        name: 'Biological Sciences III (BS3)',
        lat: 33.645363,
        lng: -117.846222,
        imageURLs: ['463/biological-sciences-iii.jpg'],
    },

    114877: {
        name: 'Biological Sciences III (BS3)',
        lat: 33.645363,
        lng: -117.846222,
        imageURLs: ['463/biological-sciences-iii.jpg'],
    },

location_ids:

    BS3: 114877,

Custom Events seemingly use the 83057 which don't exist in location_ids, whereas course events use 114877 which do.

[srukelman]

RFC: @KevinWu098 How should I handle inconsistencies, for example ids present in location_ids are not present in buildings_catalogue, and vice versa, and duplicates in buildings_catalogue where neither is present in location_ids?

[KevinWu098]

RFC: @KevinWu098 How should I handle inconsistencies, for example ids present in location_ids are not present in buildings_catalogue, and vice versa, and duplicates in buildings_catalogue where neither is present in location_ids?

Haven't delved too deep into the code, but here's some thoughts:

1. For consistency, this PR should probably ensure 1-1 parity for buildings and IDs
2. We'd want every building listed across all lists (preferably only one list total), and every building is only associated with one ID (and vice versa)
3. Ideally (IMO), we should aim to consolidate everything into one file, one source of truth instead of having multiple files
4. If parity is unachievable -- some key or value doesn't exist, you could try hunting it down 😅

LMK if that doesn't make sense -- happy to discuss implementation more