Use levelbuilder-controlled course status for deprecation

[bencodeorg]

Switches from using the is_deprecated boolean flag (a serialized property on the Unit model) to the levelbuilder-controlled Course published state to determine whether to show the "deprecated course" page to users.

Prior to merging this, we'd want to:

• mark all existing deprecated courses (a bunch of single unit "Algebra" courses and the 2017 and 2018 versions of CSP) as "deprecated" on the Course edit pages (eg, https://levelbuilder-studio.code.org/courses/algebra/edit).
• add unit tests?

Testing story

I tested manually that marking a Course as deprecated resulted in not being able to navigate to the course page (eg, /courses/csp-2019), a unit overview page (eg, /courses/csp-2019/units/1), or a script level page (eg, /courses/csp-2019/units/1/lessons/1/levels/1).

[bencodeorg]

This may be circular -- should we just check the Course's deprecation status directly? This comment is confusing me (I think the comment doesn't match the code):

code-dot-org/dashboard/app/models/unit.rb

Lines 1963 to 1967 in fbb8fc3

	# If a script is in a unit group, use that unit group's published state. If not, use the script's published_state
	# If both are null, the script is in_development
	def get_published_state
	published_state || unit_group&.published_state || Curriculum::SharedCourseConstants::PUBLISHED_STATE.in_development
	end

[bencodeorg]

This currently makes it so that once a course is marked as deprecated on levelbuilder, levelbuilders will immediately not be able to view the edit page for any Unit within the course.

We don't have the same condition on the edit page for the Course itself (maybe we should?), so the /courses/csp-2017/edit page is still viewable (but /courses/csp-2017 is not).

Not sure how strongly we feel about making these uneditable / want to come up with some other mechanism to prevent edits.