refactor and separate out dsc library from config command

[SteveL-MSFT]

Separate out the core dsc functionality as a library and reduce config command to just call the library. Eventually need to update library to have C exported functions to be used in other languages.

[gaelcolas]

This change seems to be alleviating what I was whining about regarding the separation of the "DSC-specific feature handling" with other "libs" (that I called plug-ins).
Now the question I have (that you can probably implement much later) is:

• Can we get the lib loaded based on a config file of "enabled libs", configured by their "path".
  So that when SubCommand::List is called, we call "find_resource" on all "loaded libs".

        SubCommand::List { resource_name } => {
            for resource in dsc.find_resource(&resource_name.unwrap_or_default()) {
                println!("{} = {:?}", resource.name, resource.implemented_as);
            }

The point of looking at this now is do define how you'd know whether the git resource to use is a DSC resource or a "binary command" one.
Should the git resource have a "lib" namespace like DSC.Git? is there a resolution preference order: will the DSC git resource take precedence over the binary command git resource? Should the interchange document be explicit about that (I think so)? Then how?

Note:
I would have prefered the config tool to call other binary utilities like dsc_config and only communicate through JSON to ensure strong segregation of concerns, and well defined messages/expectations, but we already discussed about that... (and I still think config should be real dumb, doing only the dispatch to "only" call list/get/set/test from the libs, so that it can implements the list/get/set/test/enact).

[SteveL-MSFT]

@gaelcolas the design of config is that it would call native resources as comand-lines passing JSON and receiving JSON. So in that sense, config is just a dispatcher. There is still a valid concern you brought up regarding the identity of a resource which currently is still just the name and any higher level tool needs to post filter the appropriate resource and invoke.