Code called inside InModuleScope now retains file / line information

This causes failed tests to output the proper file and line from the tests.ps1 file, and also allows for setting breakpoints inside these blocks.

There are two other places that currently use Set-ScriptBlockScope and may lose similar information:  Mocks, and BeforeEach / AfterEach.  I'm not sure we can do much about the latter, but we can possibly add this same type of change to the Mocking code, if needed.
Add module manifest

Unfortunately I can't set the version to Beta as it is not recognized as
a valid Version.
Reporting correct file name

For exceptions that are generated by something other than the Should command, test failure output now contains the file path and line number of whatever code produced the exception, instead of mixing the file path of the Tests.ps1 script and the line number from whatever file contained the error-producing code.

May revisit this to either change it to report the path / line number of the Tests.ps1 file (as failed Should assertions currently do), or output both sets of information.
Make module manifest compatible with PowerShell 2.0
Make module compatible with PowerShell 5.0 (and PowerShellGet and PoshCode + Chocolatey)
Add complete description from nupkg
PowerShellGet generates a nupkg from the manifest, so these need to match what you want in there.
Fix results output for comparison tests #181
Merge pull request #184 from Jaykul/Beta

Fix Module Manifest
Merge pull request #185 from Jaykul/OutputFix

Fix results output for comparison tests #181
Update CHANGELOG.md
Merge pull request #183 from dlwyatt/DebuggingInfoInModuleScope

Debugging info in module scope
Update CHANGELOG.md
Starting to make Should work on collections
"Should Be" and "Should BeExactly" updates

Original code was behaving a little weirdly, and caused some tests to fail in conjunction with the new Should on Collections behavior.  This test used to pass:

1 | Should Be @(1,2,3,4,5)

And this test used to fail:

@(1,2,3,4,5) | Should Be @(1,2,3,4,5)

This situation has been corrected in both cases.  "Should Be" now compares the elements of arrays on both sides (in order) and only returns true if all of the elements match with the -eq operator (or -ceq, in the case of BeExactly).
More Should Be and BeExactly updates

Moved these assertions into the same file, which makes sense for organization when they use the same helper functions.

Be / BeExactly now make use of the Compare-Object cmdlet, which has demonstrated more consistent behavior when arrays containing other arrays are passed to Should (though I can't imagine users actually need to do that, at least we handle it properly.)  It may also be easier to explain the behavior of "Should Be" in terms of it being a wrapper around Compare-Object.

There were a couple of tests which relied on the behavior of the eq operator in the old implementation of Should Be (automatic casting of operands).  These tests have been updated to use Should Not Be $null instead of Should Be $true (where a non-boolean value is piped in.)
Added tests demonstrating new successful array comparisons.

I know, I didn't write the tests first.  Bad me.
Fixed test

Note to self:  When copying and pasting tests, be sure to update the part that was supposed to change.
More test updates

Testing case-sensitive behavior of Be / BeExactly on elements in arrays.