Draft: Extendable configuration providers and TOML provider

[ghorsington]

Extends configuration API to allow swappable configuration readers and writers.
This PR also generally updates the configuration API.

As this is a Draft PR, suggestions and ideas are welcome.

Description

This PR cleans up and extends BepInEx configuration API. The most important changes are

• Adds swappable configuration providers
• Removes obsoleted configuration API
• Adds support for binding to compound data types (lists, data classes)
• Implements TOML configuration provider as the new default

Motivation and Context

At the moment, BepInEx supports a subset of TOML/INI with which handling compound data types is not easy.
Additionally, there have been calls for supporting writing to different configuration formats (JSON, INI, msgpack) and stores (file, memory, SQL, web).
This PR attempts to add general support for new configuration formats and sources by introducing configuration providers.

Configuration providers

A configuration provider is a low-level abstraction over a configuration store. A configuration provider implements a basic CRU(D) API and thus can

• load and save the configuration
• read a configuration node by a path
• write a configuration node to a path

A path is represented as a string[], which allows for nesting and arrays.
A configuration node contains minimal metadata to read/write a single non-compound configuration value. The layout of a node is

public class ConfigurationNode
{
    // Configuration value as a string
    public string Value { get; set; }
    // Optional comment of the node
    public string Comment { get; set; }
    // Type hint. This can be used by the writer to generate the correct output
    public Type ValueType { get; set; }
}

A single node must always contain a non-compound value (number, string, date). Compound data types are, in turn, represented as multiple nodes.

This PR will also add a proper TOML provider.

Configuration API cleanup

TODO: Plan out a new API and consolidate suggestions of other PRs.

TODOS:

• Configuration providers
  • Initial API
  • Port old .cfg reader to a configuration provider
  • Integrate with ConfigFile
  • Implement TOML provider
• ConfigFile updates
  • Ability to specify which provider to use in a BepInEx plugin (see Custom Save and Reload implementations for ConfigFile #243 and Custom ConfigFile classes for v5lts #244)
  • Ability to access entries directly (see API for accessing orphaned config entries #210)
  • Bind<T> to compound types