[Feature Proposal] Better Config API

[pbone64]

Description

The current tModLoader config system is.... kinda bad.
I propose adding two features:

1: A builder system to create configs

// Building a config
public override void BuildConfig(IConfigBuilder builder)
{
    // This lets you completely override the config screen UI. Tea provides a default config screen UI
    builder.ConfigScreen(new MyCustomConfigScreen());

    // The header "Item Options" will be used until the next Header(string) or EndHeader() call
    builder.Header("Item Options");
    
    // The full l10n keys are added for clarity -
    // To organize your code, you can instead write: new ConfigOptionMeta("ExampleSwordToggle")
    builder.Option<bool>(
        // Specifies the internal name, label, and tooltip of a config option.
        // To encourage localization, _only_ localization keys are allowed for the label and tooltip.
        meta: new ConfigOptionMeta(internalName: "ExampleSwordToggle", labelOverride: "Mods.ExampleMod.Config.ExampleSwordToggle.Label", tooltipOverride: "Mods.ExampleMod.Config.ExampleSwordToggle.Tooltip",
        
        // Specifies how this option should be displayed in the menu.
        // Developers will be able to create and use custom views, 
        // but tea will provide several default ones
        view: DefaultConfigView.Checkbox(),
        
        // The config option's default value
        defaultValue: true);

    builder.Option<int>(
        meta: new ConfigOptionMeta("ExampleBowDamage"),
        view: DeafultConfigView.Slider(min: 0, max: 100,
        defaultValue: 50);
}

// Checking a config value
if (MyConfig["ExampleSwordToggle"].Get<bool>())

2: Auto Configs

// Create your config
public class MyConfig : TeaConfig
{
    [Header("Item Options")]

    [View(typeof(CheckboxConfigView))]
    [LabelOverride("Mods.ExampleMod.Config.ExampleSwordToggle.Labe"l]
    [TooltipOverride("Mods.ExampleMod.Config.ExampleSwordToggle.Tooltip")]
    public bool ExampleSwordToggle = true; // If possible, use this to declare default values. If not, use an attribute [DefaultValue(true)]
    
    [View(typeof(SliderConfigView)]
    [SliderConfigViewMeta(min: 0, max: 100)]
    public int ExampleBowDamage = 50;
}

// Checking a config value
if (MyConfig.ExampleSwordToggle)

Notes:

• To avoid semantic hell, only value types, strings, and arrays will be allowed as config values. This way we don't have to do any deep cloning just to remember the default value.

What does this proposal attempt to solve or improve?

Currently, it's hard nigh impossible to dynamically add config options (say, autogenerating a toggle for every item in a mod) or provide custom config UI.

What (other) solutions may be considered?

Some alternative design choices:

• Only provide AutoConfigs, scrapping the idea of builder configs.
• Only provide builder configs, scrapping the idea of autoconfigs.
• Allow mixing auto and builder config options in the same config class.