XBlock Scoping

Reported by @pmitros:

"NONE and ALL mean the same things, and expose our particular implementation details to XBlock authors.

Students may want to modify a course. Examples:

• Contribute hints around a problem (experiment last summer)
• Ike's dogfood.
• MakerPhysics course, where students construct a course

See:
http://en.wikipedia.org/wiki/Von_Neumann_architecture
http://en.wikipedia.org/wiki/Harvard_architecture

TYPE should be BLOCK_TYPE

DEFINITION and USAGE should be the same. The set of things which are overridable/advertisable should not be pre-defined by the XBlock author. Especially things like number of attempts can fall into either bin, and which makes more sense depends on how they are used. This is an artificial split due to architectural issues on our side, but it shouldn't be exposed to an XBlock author.

I can see there being something here, but not this. SCOPE could have an additional axis indicating something along the lines of whether something is mutable or read-only, or perhaps whether it ought to be versioned, or whether Big Things Happen when it changes (e.g. other chunks of state become inconsistent) or something, but I'm not quite sure what that is. I'm pretty sure it's not what we've got, though."

The issue names no files, tests, or entry points. Start by mapping the existing XBlock scoping API, especially NONE, ALL, TYPE, DEFINITION, and USAGE, then review the linked Von Neumann and Harvard architecture references. Done requires an agreed replacement model before implementation can be scoped.