VDF Parsing: Add More VDF Parsing Functions

[sonic2kk]

This PR adds various new VDF parsing functions that we can use when manipulating VDF block values.

• getNestedVdfSection - Allows for searching for the first match of a given VDF section path, including an optional indentation level to start searching from.
  • Usage: getNestedVdfSection "/vdf/section/path" "startIndentation" "vdf_file"
  • Example: getNestedVdfSection "Valve/Steam/ShaderCacheManager/App" "1" "$HOME/.local/share/Steam/config/config.vdf"
• getVdfSectionValue - Return the value of a VDF property within a given block.
  • Usage: getVdfSectionValue "sectionString" "propertyName"
  • Example: getVdfSectionValue "$( getNestedVdfSection "App/1234567890" "OverlayAppEnable" ""$HOME/.local/share/Steam/userdata/xxx/config/localconfig.vdf" )" "OverlayAppEnable"
• createVdfPropertyString - VDF properties follow a fixed format, this helper function can generate a VDF property string preparing it for entry in a VDF block.
  • Usage: createVdfPropertyString "propertyName" "propertyValue"
  • Example: createVdfPropertyString "DisableLaunchInVR" "0"
• prepareJSONVdfProperty - We need to escape JSON strings before entering them into a VDF file, in order to preserve the escape sequences that the VDF file expects. This function does the heavy lifting and even manages removing start and end quotes when needed.
  • Usage: prepareJSONVdfProperty "stringifiedJSON"
  • Example: prepareJSONVdfProperty "{"hello": "world", "foo": { "bar": ["foo", "bar"], "foobar": true, "barfoo": false }}"
• substituteVdfSection - Helper to replace an exact VDF section in a given VDF file with a manipulated one.
  • Usage: substituteVdfSection "oldSection" "newSection" "vdf_file"
  • Example: substituteVdfSection "$( getNestedVdfSection "App/1234567890" )" ""\1234567890\"\n{\n\t\t\"foo\"\t\t\"bar\"\n}" "vdf_path" -- Indentation doesn't match here, but just an example (mainly meant for use by addVdfSectionValue and editVdfSectionValue below)
• addVdfSectionValue - Add a new value to a VDF section. It will also auto-detect when we're dealing with a JSON string
  • Usage: addVdfSectionValue "vdfSectionString" "newPropName" "newPropVal" "vdf_path"
  • Example: addVdfSectionValue "$( getNestedVdfSection "App/1234567890" )" "MyProp" "0" "vdf_path"
• editVdfSectionValue - Edit an existing property's value within a given VDF section. Also auto-detects and handles JSON strings elegently
  • Usage: editVdfSectionValue "vdfSectionString" "updatePropName" "updatePropVal "vdf_path"
  • Example: editVdfSectionValue "$( getNestedVdfSection "App/1234567890" )" "OverlayAppEnable" "1" "vdf_path"

---

There are also some (temporary) examples to proof out how we can use these functions in some upcoming work, such as for setting/updating a Non-Steam Game App entry in localconfig.vdf to toggle whether the Steam Overlay should be enabled for a given app. There is also an example of updating/creating the user-collections value to mark a Non-Steam Game as hidden. In future, we should be able to use this to add a Non-Steam Game to a collection, once we are able to reliably get the list of collection IDs by name to write into this JSON block.

---

These functions are not really used yet outside of the debug scenarios in the code, but are a prerequisite to some upcoming work. They will allow us to do the following:

• Update existing CompatToolMapping entry when adding Non-Steam Games
• Fix setting Non-Steam Games as Hidden (currently set in VDF but does nothing, it is handled in user-collections in localconfig.vdf
• Fix setting Non-Steam Games AllowOverlay option (currently set in VDF but does nothing, it is handled in "Apps"/appid section of localconfig.vdf)
• Eventually, fix Non-Steam Game categories, once we can get their LevelDB ID (see Non-Steam Game Categories Not Working #949 for background on where and how they're stored). These functions will allow us to insert into user-collections once we have the collection ID though.

---

TODO:

• Code cleanup
• Version bump

[sonic2kk]

Version is bumped, shellcheck is green (apart from a couple of disables, one for a debug var and another for some style changes I didn't prioritise), and these functions shouldn't break any existing functionality. This should be ready to merge!

In future maybe we could add more logging, but I felt it was a bit too noisy for right now :-)