Renovar la relación entre cursos/equivalencias/bloques

[kovaxis]

Lo siento por la PR gigante xd juro que es la última así

Contexto

Hasta ahora hemos guardado los cursos de un plan "pelados", es decir, sin un bloque asociado. La razón detrás de esto es que para un cierto plan siempre es posible encontrar la asignación "óptima" de bloques, que siempre cumpla con el curriculum si se puede.

Sin embargo, esto es un problema para la experiencia de usuario, porque implica que Planner decide por sí mismo qué cursos van con qué bloques, y esto puede ir en contra de lo que realmente quiere el usuario.

También, antes asociábamos algunos cursos a "equivalencias", por ejemplo si seleccionabas un OFG el curso "recordaba" que era un OFG, y evitaba recolorearse como algo más (un biológico, por ejemplo).

La idea es mezclar los dos conceptos. Ahora todos los cursos "recuerdan" a que bloque pertenecen, no solo los cursos que pertenecen a equivalencias como los OFG. Esto significa que los conceptos de "bloque" y "equivalencia" se volvieron muy similares. En particular, incluso los bloques de 1 ramo como "Cálculo 1" tienen su propia equivalencia (que solo contiene a MAT1610). La gracia de hacer esto es que un ramo puede recordar si está asignado al major o al minor, por ejemplo.

Incluso los ramos pasados tienen una equivalencia asociada. Esta equivalencia se decide al momento de generar el plan, o al momento de actualizar un plan desactualizado.

El solver ahora también tiene soporte para "recolorear" ramos si esto mejora el desempeño del plan (ie. si permite ahorrarse cursos). Agregué un nuevo warning que indica cuando es posible recolorear para ahorrar ramos.

¿Qué se implementa?

• Todos los cursos tienen una equivalencia asociada (menos los cursos que no se pueden asignar a nada). (closes [Feat]: Pertenencia de bloque de los ramos #322)
• Usar códigos de equivalencia más estables en lugar de !!MOCKn.
• Migraciones para los planes antiguos que tienen cursos sin equivalencia y códigos de equivalencia antiguos. (IMPORTANTE: Las migraciones son para los planes creados por la version en main. La versión en dev crea planes con un formato que ojala nunca volvamos a ver xd)
• Soporte para reasignar/recolorear cursos en el solver.
• Refactor del planDigest y validationDigest: ahora son funciones auxiliares cacheadas.
• Cargar todas las equivalencias del curriculum de a una sentada al cargar un plan. Simplifica varias cosas y son <30KB descargar todos los EquivDetails de un plan.
• Exponer al frontend una lista de todos los bloques posibles para un curso (en Planner.tsx, marcado con un TODO como possibleBlocksList, y se usaría para implementar [Feat]: Botón en el context menu para cambiar el bloque asociado a un ramo #352 y [Feat]: Reemplazar equivalencia desambiguada al agregar curso extra que la satisface #319).
• Priorizar los cursos pasados antes que los futuros en el solver. (closes [Fix]: Priorizar los ramos pasados antes que los futuros al momento de asignar bloques #380)
• Comprimir las respuestas del backend con GZip.
• Mejorar el mensaje cuando un curso no está disponible: No hay registros que alguna vez se haya dictado el curso {...}: es posible que no se siga dictando.

¿Qué falta?

Creo que es un poco difícil revisar todo el código de esta PR, pero no sería malo pasarle un segundo par de ojos por encima. Más importante es probar que todo funcione bien. Probé las migraciones desde producción, y todo parece estar bien, pero siempre se pasan cosas.

Tras probar esto un poco, estaríamos en un estado para deployear dev a mallastest, y así "liberaríamos las mallas que faltan".

Después de eso, tocaría trabajar en #352 (botón para cambiar el bloque asociado a un ramo) y #360 (botón para cambiar un ramo por otro) en el frontend, que son opciones del context menu que harían trabajar con Planner 1000% más fácil y claro.

También con estos cambios cobra sentido #319 (asignar una equivalencia a los ramos agregados con el +), y se vuelve atractivo implementar #318 (mostrar el bloque asociado a un ramo).

[Diegothx]

Si es sumamente necesario revisar el código en detalle entonces ojalá que @fagiannoni de su approve de todos modos, ya que se maneja más que yo con el código del backend. Sin embargo, por mi lado he estado testeando los cambios y todo se ve OK, además, viendo que ya existen múltiples PR construidas sobre esta misma (tanto de @kovaxis como una mía) asumo que ya habríamos encontrado errores de esta PR si existieran