Added a bunch of tests to test ValueByPipelinePropertyName
Handling of 'Property' paramter in New-Object cmdlet
Various fixes for support of  ValueFromPipelineByPropertyName
Added a bunch of tests to test ValueByPipelinePropertyName
Various fixes for support of  ValueFromPipelineByPropertyName
Refactor: "params" in NewlineJoin saves lots of syntax.

I don't know why I didn't think of it when I introduced that function.
NewlineJoin with variable parameters now provides a simple way to generate
expected output strings, multiline commands, scripts, etc. All without much
syntax overhead.
Merge pull request #207 from sburnicki/cmdlet_pipe_byprop

Support for value binding by property name in pipeline
Merge pull request #208 from sburnicki/reference_host_refac

Refactor: "params" in NewlineJoin saves lots of syntax.
Refactor: Introduction of Formatting/Output Framework

This is a huge refactoring commit that does not change the functionality, yet.
Investigating the proper way to implement data formatting and output I saw that
the underlying framework in Powershell is very extensible.
So I introduced another framework that can and will be used for proper formatting
and output and should be easily extensible.

From a user's perspective there are two types of commands:
  * The Format-* family which formats the output but is independent of where
    the output goes to
  * The Out-* family which doesn't support formatting arguments but defines
    where the output goes to (console, file, null, ...)

The underlying mechanism works as follows:
The Format-* commands work the same in general an generate specific FormatData objects
that represent a document with the following structure
	FormatStart
		[GroupStart
			[FormatEntryData]*
		GroupEnd]*
	FormatEnd
where the []* denotes structures that can repeat (multiple groups). The FormatEntryData
includes the real data to be printed and might be a row of a table.

The content of these objects depend on the *Shape* of the output which might be
a table, a list, etc. Thus, it's generated by a specific FormatGenerator class for
the specified shape.

If a command of the Out-* family is called, it implicitly checks whether the input is
already formatted or invokes default formatting ("Format-Default").
The format data is than processed by a FormatProcessor, which of course depends again
on the shape of the output, as the FormatData objects may have different forms and contents.
For example the TableFormatGenerator generates some FormatEntryData that specifies the columns
used, etc. The TableFormatProcessor will the string representing the row of the table in the console
and passes the string to the OutputWriter.

The OutputWriter could then be a class that prints it to console, writes it to file or even creates
any other file including the formatted output.

For now, the FormatEntryData class, the TableFormatGenerator and TableFormatProcessor classes were
misused to implement the stupid old way of printing objects by simply using it's ToString() method.

The real implementations for at least the table and list view will with other commits.
Refactor: Distinction between formatting non-objects and objects
working commit
working commit
Working commit