Starting to add sample configuration and documentation of tooling modules

For now, there's a bunch of explanation via inline comments in this sample module.
This will probably be pulled out into a wiki or readme file later.  It's helpful
to see the sample code, though, when discussing the relationships between nodes,
sites, services and roles.  The design of the DscConfiguration module and the
Resolve-DscConfigurationProperty command didn't really click for me until I saw
a sample configuration script much like this one.

Still to do, build a sample configuration data DB, and update the configuration
sample to use it, rather than hypothetical usages in comments.
Converted tab to spaces in New-*Metadata commands
New-DscNodeMetadata update

Removed required ServerType parameter, which may not be something that all clients require.  All nodes still require a Name, Location (should probably rename this to Site) and NodeName (which will be a randomly generated GUID, if one is not passed in.)

Also fixed duplicate Position attributes in the parameter metadata, which was causing the Name parameter not to show up in Get-Command New-DscNodeMetadata -Syntax .
Removed forced upper-case of ConfigurationData file names.
Added basic (mostly empty) sample ConfigurationData files

Samples will show three nodes in two sites, three services, and three roles with various amounts of overlap.  This should be sufficient to cover all of the ways a configuration can resolve properties in the ConfigurationData table.
Updated sample configuration and DB

Samples now contain demonstrations of service and node interaction using the current code.  Still need to add some site and node data which is not in a service (and potentially add another Node which is not a member of any services.)
Added site/node override example.

Just used Write-Verbose and some nonsense property names to demonstrate this for now.
Moved Resolve-DscConfigurationProperty to DscConfiguration module

It was likely a part of dscbuild due to how it used to use Get-Variable -Scope ## to look up the value of the $ConfigurationData variable in parent scopes.  This was probably intended to find the automatic variable of that name inside the DSC configuration functions, but Get-Variable doesn't cross module scope boundaries.

This code has been updated to use $PSCmdlet.GetVariableValue() instead, which looks up the ConfigurationData variable in the caller's scope stack (regardless of which module the caller happens to be in), allowing the function to reside in the DscConfiguration module, where it makes the most sense.
Moved Test-NodeHasRole into DscConfiguration module
Updated Pester test code to work with new variable resolution technique.

$PSCmdlet.GetVariableValue returns the value of the parameter, if the caller happens to be in the same module / sessionstate as the Resolve-DscConfigurationProperty function.  Normally, this is not the case, but because of the way the test script was loading the ps1 file instead of just importing the module, this was breaking the tests.

It shouldn't be necessary to "fix" this behavior in the module itself, since nothing within the module calls Resolve-DscConfigurationProperty, nor should there ever be a need for that.
Added failing test for new nested property resolution feature
Added new utility function for resolving nested hashtable properties.

Will revise old code to leverage this new function.
Nested property resolution partially implemented

Assert-NodeOverride has been updated with new behavior for PropertyName lookups.
Added more failing tests for Site / Global nested property resolution
Nested property resolution implemented for Site and Global overrides

For now, there are some goofy branches to the new code from the various Assert-*Override functions.  I think I'll be ripping out the Application and ServiceName stuff in the near future anyway, so it is probably a waste of time to update those sections.
Formatting cleanup

Replaced tabs with 4 spaces, removed trailing whitespace from all lines, and set file encoding to Ascii
Revised new tests for consistent naming
Preparing to gut Resolve-DscConfigurationProperty

The Application parameter is going to be gone, and ServiceName may go as well.  Test for service overrides is deliberately failing in this commit; it's reflecting the new behavior that is coming up.
Resolve-DscConfigurationProperty revised

Internal logic almost completely rewritten to produce a scheme that's still just as powerful (or more so), but also much easier to understand when looking at the raw data files.
Updated samples to use new Resolve-DscConfigurationProperty behavior.

Also added -DefaultValue parameter to Resolve-DscConfigurationProperty, and added Test-DscConfigurationPropertyExists command (taking the place of the old Test-NodeHasRole, which has been removed.)