Re-architect options to be more pluggable

[AadamZ5]

Re-architecting the current implementation to allow a more pluggable language listing could make for easier contributions.

Perhaps something like a list of defined regex matches for a Language option could allow for more language flexibility. This could be serializable and read from a config file, with a sane programmed default config file that is auto-generated.

use regex::Regex;
use serde::{Serialize, Deserialize};
use serde_regex; // Helper to serialize and deserialize RegEx

#[derive(Debug, Serialize, Deserialize)]
struct LanguageOption {
    /// The name of the language option. 
    option_name: String

    /// The RegEx that matches the target folder to be removed
    #[serde(with = "serde_regex")]
    target_folder_regexp: Regex,
    /// The optional RegEx that matches what the target folder must contain
    #[serde(with = "serde_regex")]
    target_folder_contains_regexp: Option<Regex>, //Maybe a list of Regex entries instead for multiple files
    /// The optional RegEx that matches what the target folder's parent must contain
    #[serde(with = "serde_regex")]
    parent_folder_contains_regexp: Option<Regex>, //Maybe a list of regex entries instead for multiple files
}

As seen above, adding serialization options for this allows these language options to be read from an external config (need appropriate serde_json or alike crate), which means users could add their own rules and options to this command.

Additionally, I imagined some additional struct fields for adding items that the target folder must contain, along with the parent folder. I think this might help alleviate #15

Example config:

[
  {
    "optionName": "MyWeirdEsotericLanguage",
    "targetFolderRegexp": "/someregex/",
    "targetFolderContainsRegexp": "/somefile/"
  }
]

or perhaps instead with multiple matches:

[
  {
    "optionName": "MyWeirdEsotericLanguage",
    "targetFolderRegexp": [
      "/someregex/",
      "/someotherregex/"
    ],
    "targetFolderContainsRegexp": [
      "/somefile/",
      "/someotherfile/"
    ]
  }
]

I think this would increase complexity about where to store the config and be cross platform (not sure if cross-platform is a goal currently), but would allow for that flexibility increase.

If I get some time, maybe I'll entertain a PR with an implementation of this :)