Refactor to avoid accessing StudentModule models directly

[pdpinch]

from #52 (comment)

An XBlock should never directly access StudentModule models directly. Anything you need from the modulestore or form the StudentModule models should be available through XBlock services, or we should create new XBlock Services to safely expose what's needed.

The username should be available now. An XBlock user service was created recently and could be leveraged here. It appears the module state is being retrieved to view student state from one user to another. You can avoid the need for accessing the state directly by adding the annotated_filename to the submission JSON blob as an arbitrary attribute. This will be useful in debugging anyhow, to have all relative information captured in the submissions table.

[pdpinch]

• Create an XBlock API and implementation to get all users for a course #115 XBlock API for get_course_users(). A specification exists, but it hasn't been implemented yet. Theoretically could move the existing code for getting all users out of SGA and reuse it in XBlock. See PR #6013 in edx-platform and Release 0.11.1 #273 in XBlock. 4
• Refactor to use the XBlock User service #116 refactor SGA to use the xBlock user service from above 3 (not in the same sprint)
• discovery: is there a way we can avoid using access StudentModule state for the instructor annotations. i.e. what would it take to add a file field to the submissions api? This includes an e-mail to the edx-code list. 3