Create a user-facing ASCII format for nodes and subgraphs

[Keavon]

Currently the CopyBufferEntry is serialised using JSON when a user copies a layer:

{
	"nodes": {
		"2": {
			"alias": "custom alias",
			"name": "Transform",
			"inputs": [
				{
					"Node": {
						"node_id": 3,
						"output_index": 0,
						"lambda": false
					}
				},
				{
					"Value": {
						"tagged_value": {
							"DVec2": [
								5.049571603427239,
								118.83782129742963
							]
						},
						"exposed": false
					}
				},

However this should be changed to be in a format that looks something like:

[node parent(4) / transform(2)]
alias = "custom alias"
position = [1, 3]
vector_data = { node_id = 3, output_index  = 0 }
translation = { value = [5.04, 118.8], exposed = false }

whereby each input is stored in snake case if it is overwritten.

[0HyperCube]

I'm not sure I quite understand the meaning of this? Is this the same as creating a stable document format such that the node graph can be fully encoded? How would you envision this format to look like?

[Keavon]

This is essentially a DSL serialization format which minimally encodes anything a user might copy from the graph. Essentially it would act as a canonical ASCII format for a Graphene graph's source code.

The purpose is to let users copy and paste nodes into forums, etc. to share their node setups, ask for help, etc. It also makes it easier for users, on the rare occasions it's needed, to manually edit the values more ergonomically than today's experience editing the JSON of a .graphite file to update its format.

We could also simplify our .graphite file encoding by using this syntax instead of the highly verbose JSON (that would be part of #1609). This will also potentially be the format we end up saving in the future .gdd file format (although our plans for version history and CRDTs might mean we end up encoding it differently in the end).