Reconsider sysand build emitted .meta.json / .project.json files

[consideRatio]

My preference order of what we bundle into the .kpar is:

1. Leaving the .json files unchanged, besides minimal changes such as updating a field (checksum etc) without changing structure
2. Reformatting them in a canonical and "pretty" way for human readability
3. Reformatting it to a space saving single line kind of thing

To have these files be readable is an upside (even from within a .kpar)

• it can help curious people learn and verify their understanding etc.

To have them mostly identical to the original version is also an upside

• if we have a error when validating a .kpar bundled .json file reporting a certain line number - then that line number is more accurate than if we made significant changes.
• it avoids introducing unexpected behavior, which raises questions

To save data space is worth very little in comparison, especially since the file will be part of a .kpar (zip) that can combine misc space characters etc to save the kind of space we could trim.

[andrius-puksta-sensmetry]

During build, metadata is read, modified in memory and then written into the kpar. So this essentially rules out option 1. Option 3 is what we currently do. The question is whether to switch to option 2.

Option 2 is what we use for every non-kpar write, so using that for the kpar also would improve consistency.

[consideRatio]

Option 2 is an improvement from option 3 in my mind!

Doing option 1 is harder than option 2 for sure. With YAML, which has comments, its essential to be able to do "round-trip updates" as you don't want to loose comments or how they are positioned in relation to the content. I'm not sure whats required to do round-trip update of the JSON, but its for sure more work than option 2.

I don't want us to block doing option 2 just because option 1 may be preferred, option 2 is a significant imporvement!