support modules in pjs environment

@ChrisJPhoenix @MikaalSky and I were discussing this on our brand new gitter channel https://gitter.im/Khan/live-editor. I've tried to summary as well as add some additional concerns and information about future integration with webapp.

We'd like to eventually allow users to import code from other scratchpads. As a first step we'd like to support modules within a scratchpad. This will allow users to break their programs into one or more application and or library modules.

Modules would export code using the CommonJS standard `module.exports = { }` and `exports.property = ...` patterns and would import code using `var A = require("./lib_a.js");`.

Out of scope for initial support would be importing code from another scratchpad. This is because we'd want to be able to pin the version of a scratchpad that a person is importing from so that the code doesn't change from underneath them if the original author makes a change. This is also necessary for importing code from your own scratchpads because we'll probably want "spin off" to only spin off a project and not all its dependencies because that would get messy quite quickly. Before we can handle any of this we will need a way to surface information about versions to users as well as allow users to switch between versions.

For the UI we could have some sort of tab interface where each tab would have the "filename" of the module. If there are too many modules to display all of the tabs we could use a list modal to switch to a file that is out of view. That new tab would come into view and the least used tab would be moved out of view.

For the data storage we'll have to change how scratchpads are stored. There is an internal server end point which returns a Scratchpad entity as JSON. There is a "revision" property which contains a ScratchpadRevision entity as JSON which contains a "code" property which is a string. I think it makes sense to update this to be a JSON object where the keys are filenames and the values are the contents of each of the files.

Although we can make changes to live-editor to handle "code" that's a JSON object and display multiple tabs, we'll have to put this functionality behind a flag until webapp can be updated. It's probably easiest to add a new property to ScratchpadRevision to store the new "modularCode". This change will require updating webapp in a lot of places. This work will require someone at KA to make those changes but it's hard to say when resources will be available to make those changes. Simply keeping stuff on a branch until we're ready to make those changes doesn't work either because that branch will die. That's why hiding the code behind a flag is necessary.

Start by tracing the internal endpoint that returns Scratchpad and ScratchpadRevision JSON, especially the revision's code property, then inspect live-editor's UI and storage entry points for feature-flag handling. Done would require an agreed initial design and coordinated support for multiple module files, CommonJS imports and exports, tab navigation, and modularCode storage without enabling cross-scratchpad imports.

Written by the indexing model from the issue text.