Refactor and improve configuration loading

[nassah221]

This PR addresses #15 by adding typed configuration variables in the config pkg. I have also been able to remove viper from the dependencies and replaced it with a much slimmer config loading pkg.

Typed configuration values have allowed to create elaborate constructors w.r.t. different configurations for each of service, orchestrator, inputs and outputs and the code looks much cleaner now IMO.

I have also renamed some of the packages to be more in-line with go convention e.g. dummy_orchestrator is now dummy. The import project_dir/pkg/orchestrator/dummy makes the intent clear.

One caveat though is that I had to make changes to the base config.toml template by adding list/slice of inputs, outputs along with removing redundant .dummy keys from orchestrator and service values e.g.

[input]

[[input.sources]]
type = "rtmp"
address = ":1935"

// [orchestrator.dummy] is now
[orchestrator]

I hope the template modifications aren't breaking changes.

P.S. I broke up the commits for easier reviewing so ideally they should be squashed into one before merge.

[clone1018]

Hey! This looks good overall, thanks! One idea we need to keep (which I think is still supported by this?) is the ability to run multiple types of the same input or output, with different configuration values. For example running two RTMP servers on two different ports, maybe each with different bandwidth limits.

I was able to change my local config just fine, and the project runs & compiles well!