Graphs should be stored in a single collection

Currently, graphs consist of items in graphs (metadata), activities, operators and connections. This has multiple problems:

when syncing data, rendering begins immediately - if an connection arrives before the operator it references, it will crash
copying graphs means copying all of the underlying elements
when copying graphs, all items get new IDs, which means that all internal references (connections etc) must be updated, which is complex and error-prone
the fact that it's a bit complex to copy graphs means that it's harder to implement functionality such as revisions, checkpoints etc.

Plan:

graphs are stored as a single nested object in the graph collection (thus you would have an object looking a lot like the current data export, which has graph: { activities: [{id: 'a', name: 'chat'}]} etc.
there is a separate collection for the activity library, which keeps activity configs independent of the graph library (we can create activities independently and then include them in graphs, or share graph activities with the library. In both cases, activities are copied between one to the other, but reference is kept through "parentID" or something like that)

Issues:

we need to look at how the syncing of big objects works between the front-end and back-end. Currently we for example write to db on every keypress in config. In the future, we might want to only save every 20 seconds or something, which requires local state in config.

chili-epfl / FROG