UI editor for use in Studio (OC-513) (WIP)

[bradenmacdonald]

This is the first complete, working version of what we're calling "Mentoring v2"

Testing notes:

• Requires https://github.com/edx-solutions/xblock-utils/pull/5
• Make sure you refresh python entry points (python setup.py develop) before use.

Changes from v1:

• LightChildren replaced with normal XBlock children
• Instead of being edited as XML, components are now edited using the studio UI like any other block. This means that you can add/remove/edit all the various components using the familiar Studio patterns. The editing process is much more WYSIWYG in many parts.
• As a consequence of the first two changes listed, the XML representation of mentoring blocks has changed significantly. All the changes are documented in code in xml_changes.py. Since people will in general not be hand-editing XML anymore, this doesn't really affect users.
• Removed our custom HTML block in favour of the HTML blocks already available in edx-platform and the workbench. This may be a problem for jquery-xblock users??
• A new migration script was added that can go through a course and automatically upgrade all mentoring blocks it finds to the new format. It is non-destructive, so if it doesn't work, the script can be re-run multiple times.
• Added new unit tests to check for XML compatibility with the old version.

Author concerns:

• In v1, for MCQ or MRQ choices, the correct answer[s] was specified using "display" or "reject" attributes on tip elements associated with specific questions. That seemed strange to me and was harder to implement with real children, so I created fields on the MCQ/MRQ themselves: correct_choices is a field for MCQs or Rating blocks, and required_choices and ignored_choices are new fields on MRQ blocks. Unfortunately setting which choices are right is now slightly awkward, but I think it's better than it was before, and I think we can always tweak the UI to make it easier.

[Kelketek]

You should just be able to do a relative path to the image file, and Github will grab it properly. Using these hashes like this means that if the file is updated later, it will not automatically update the README. I know this isn't really something that's directly in the scope of the PR, but while we're here...

[antoviaque]

The review on this will happen in #4 so merging.

@Kelketek As discussed yesterday, unless you post your comments on the commits themselves, they will only appear in the PR you have posted them. Can you repost your comments above in #4 ? Thanks!

[Kelketek]

@antoviaque Comments ported. Sorry about that, got confused a bit.