Simulator file versioning

The Wing SDK produces .wx files (henceforth called "simulator files") that can be processed by the Wing SDK's simulator API and the Wing Console to simulate an application and all of its resources. The format of simulator files has not yet stabilized, so its structure may change. If the Wing Console tries loading a simulator file using the SDK with a different version of the SDK, then it could produce unexpected behavior (e.g. if two versions of the SDK implement the Queue resource differently) or it could fail entirely (the names of files inside the tarball could be different, etc).

As a short term solution, we can add metadata to the simulator file stating which SDK version was used to produce it, and expose the SDK version as a property on the Simulator class so the console can check if the version matches the version of the SDK in use, and error or warn the user.

For a long term solution, we should embed resource simulation code directly within the simulator files. Only if the the simulator file format changes substantially (=> major version bump to the SDK) should a simulator file be rejected by the console outright -- this shouldn't happen often though.

Start by locating simulator file generation and the Simulator class, then trace how the Wing Console loads .wx files. Define how SDK-version metadata is stored and exposed, and how a version mismatch should produce an error or warning; the long-term embedded simulation-code proposal requires separate design work.