Add model changes for real classes

[Blu3spirits]

This is the 'staging' commit for all the work that needs to be finished before we can implement the CourseShell model.

Notes:

• Renamed Course model to TransferCourse
• Changed access url to /api/transfer-courses
• The new url endpoint will be /api/courses for the joined viewset
• Added base model for real MTU classes
• This WILL break deployments since the sync scripts cannot yet write to the correct model. The scrape script for MTU classes needs to be finished first.

[Blu3spirits]

Usually USD values are stored in databases as cents to avoid rounding errors; but I guess it doesn't matter as much here since we're not calculating anything off them. Up to you.

I hadn't heard that before but I see the sense in it. However looking at the data MTU stores the data with only two decimals anyway so really I don't see any issues coming about from this. I do think that eventually with the cart system a "total fees" would be useful to have. If it does become an issue ever we can switch over. Or I can increase the floating-point limits.

[Blu3spirits]

That being said, would using an enum or something for this field make more sense? I guess it doesn't have to be here but we should have a static list of possible tags somewhere so we can map them to values if necessary. I.e. tags with value 'Online' we may want to display with a yellow background.

I don't really think an enum would make sense since it would require a code and database change for a new tag. With this current tag model, it's very arbitrary on purpose so that we can actually do things like labels based on location. In the sync script that feeds from the scraper we just do a update_or_create() model method that creates a new label and applies to the current object. Since that bit of if location == 'online' would have to be handled it would effectively end up being static list anyway.

I think farther down the line as well after we collect data from rate my professor we could also add a tag to show that.