Overhaul API structure, add multi-peer-messaging

[flaki]

To better support the application structure (and in anticipation of future enhancements, like WebSocket or WebRTC support to obsolete polling), overhaul and simplify the API structure.

Also create a simple "multi-peer-messaging" API that lets peers communicate via designated messages (through message polling, server-forwarding via WebSockets, or even peer-to-peer via WebRTC). The messaging API should be able to support these different underlying protocols.

[flaki]

Initial API design:

API

// Initialize
/init (after creating new session, save cookie) -~-> GET /editor
GET /editor/:session? (if not authenticated) -~-> /

// In the editor
build
load -> edit
sources
files
edit
> POST /build {JSON}
save {filename} file, update contents to {contents}, if build -> generate new build
/load === /init
both are equivalent, make sure /init detects the XHR call, redirects to /edit
/sources, /files -> {JSON}
return a JSON list of sources/files
GET /edit/:file? -> {file contents}
POST /edit/:file? -> updates {file contents}

// Setting session variables
do
sprite
flash
> POST /msg {JSON}
JSON contains a command to send to any peer:
{ who:"", cmd:"", data: {} }
who: defaults to the server

set session variables
> "server", "set", { var, value }

start build
> "server", "build", {}

list peers
> "server", "peers", { type? }
server, editor-0, editor-1..., painter-0, composer-0, flasher-0

start flashing
> "flasher-0", "upload", {}


> GET /msg
polls for messages

// TODO: connect command to connect via websocket

// Flasher
/flasher/poll (do I need to flash?)
/flasher/connect (websockets)

// Simplify external API
// last build should be copied to build dir as build.hex
src/hex
> GET /fetch/:file {filename|filename.ino|lastbuild.hex}
> GET /fetch -> {JSON}

[flaki]

Init detects the XHR call...

req.xhr