Let guest users try out editing functionality in sandboxed environment

After allowing unauthenticated users to see public projects and their contents (#320), also allow them to try out all the editing functionality. These changes should never be sent to the backend and should be forgotten when the guest closes the browser tab. The guest user sees a private version of whichever public project they opened, which never leaves their browser.

I think this sandboxed environment will be easier to implement than it might seem at first sight. I think we only need to switch between two alternative implementations of `Backbone.sync`, depending on whether the user is currently authenticated or not:

1. **Regular, write-capable `sync`.** Exactly the same we already have, but now only used for authenticated users.
2. **Sandboxed `sync`.** For read requests, it behaves identical to the regular `sync`, but for create, update and delete requests, it simulates the backend's response without actually sending a request. This is used for unauthenticated users.

This approach is not trivial, but it should be easier than having to sprinkle special logic all over the frontend, and I think it will also be easier and more robust than having a special, permanent sandbox project that needs to be periodically reset by the backend, as discussed in the remainder of this description. The only real gotcha is that the sandboxed `sync` must not prevent the user from authenticating.

@tijmenbaarda we discussed an alternative solution, which consisted of creating a special sandbox collection with public write permission and a periodic data reset. Compared to the approach I'm proposing here, that solution has a few drawbacks:

- Allowing write access to unauthenticated users.
- Difficulty to source records to work with. After we talked today, I also had the opportunity to talk to Jeroen and he told me that the sandbox was intended specifically to play with the contents of the curated public collections. Guest users are not supposed to work with records that weren't already in those collections (#321). If the sandbox project is separate from the project that contains the curated collections, then guest users cannot move records from the curated collections into the sandbox project because of #319. To work around this, we could copy the contents of the curated project into the sandbox project as part of the data reset, but there is always the possibility that a humorous guest user decides to delete all records, leaving nothing to work with for other guests until the next data reset. Data reset is also expensive in this case.
- The guest does not start with a clean slate, compared to the curated project (unless they happen to visit right after a data reset). For Jeroen, this was a reason to prefer my proposed solution instead.