Add initial ARCHITECTURE document

[Dekkonot]

A while ago, I was reading a blog post by the creator of Rust Analyzer recommending an 'ARCHITECTURE.md' document for sufficiently large projects. That blog post is here if you're curious.

While I don't think we need a lot of what they're suggesting, I think a document in the same style would be very helpful for Rojo. While it's fine for only a handful of people to know everything about the codebase, having a map of it and the mechanisms it uses would make directing new contributors significantly easier.

To that end, I've drafted an initial version of an 'ARCHITECTURE.md' document. It's incomplete, but I'm hoping that having a baseline will allow us to add to it over time and make the job less obnoxious; one person shouldn't have to write and maintain all documentation.

[u-train]

So, I have a different idea on how to start the document. I think we should start with ServeSession first instead. It's the core of Rojo, since the command line interface and web API depends on ServeSession and ServeSession uses a lot of the codebase (ChangeProcessor, Vfs, RojoTree).

Bringing it up first gives the context to the rest of the codebase and why it does the things it does. For example, it's impossible to explain LiveServer (which backs serve) without explaining ServeSession and its API.

[boatbomber]

We should also document the structures in the plugin, like PatchSet. It's particularly important because of how inconsistent things are with camelCase and PascalCase in our structures across the project.

[boatbomber]

We'll need to do this with Plugin and Server headers in this section due to the duplicate naming (ie: ServeSession) making the distinctions critical.

[boatbomber]

Following up
Because this doc is just meant as a high level introduction to Rojo functionality, we don't need to document the details of every plugin structure. I do think PatchSet is still very important to document though, because its the main thing the plugin interacts with during core functionality.

[Dekkonot]

We have a dedicated Plugin subsection that this can go in if need be, though maybe it's worth giving the Plugin its own document?