Add version numbers to requirement files to track BC-breaking changes #371
Description
Sometimes, changes are made to requirement files that not backwards compatible with the user's existing settled courses.
This could be tracked by version numbers on the requirement files, where an increase in version number indicates a backwards incompatible change.
For example, suppose that a requirement is changed such that a certain course that used to satisfy it no longer does. A user may have already settled that course in this requirement, which can clearly cause issues.
As another case, consider a course that can satisfy two possible requirements, reqA and reqB, and that was settled by the user in reqA. Now suppose requirement reqA is removed from the requirements file. Now, the course appears to be already settled, so it will not be made available to be settled in reqB, but it is "settled" in a non-existent requirement, so there will be no way for the user to unsettle it.
The current workaround for all these cases is for the user to remove and readd the offending course, but of course, users do not know to do this without being explicitly instructed to do so, and even if they do, it's quite annoying.
This is why the version numbers would help. Every time a backwards incompatible change is made to a requirement file, its version number is increased. Then any courses settled under the previous version of this requirement file are automatically unsettled for the user, without the user needing to do anything.
This would be done by having settled paths be version specific, so they will be ignored if they don't apply to the current version of the requirement file.
This eliminates the need for the user to remove and readd their courses to unsettle and resettle them. Also, it would only unsettle the courses for that specific major that was updated, and not for all majors (as happens when you remove and readd a course).