(Not)Be(Abstract|Sealed|Static) class assertions implemented

[melchiork]

For #645
Assertions for types (abstract, sealed, static) added. They are based on C# understanding of those keywords, as in CLR they differ.

[jnyrup]

Looks good to me.

The only minor thing that caught me eyes was that:

• NotBeSealed uses "to not be".
• NotBeAbstract uses "not to be".
• NotBeStatic uses "not to be".

We aren't entirely consistent in what we use.

• 15 uses of "to not be"
• 37 uses of "not to be".

[melchiork]

@jnyrup Thanks, fixed. Also I've added two examples to the docs.

[jnyrup]

It just struck me that from a C# perspective the keywords sealed, abstract and static are only applicable to class like types, and not interfaces or structs.

Several assertions in TypeAssertions checks if the type is an interface.
One example is BeDerivedFrom as you cannot derive from an interface type, but implement it.

[dennisdoomen]

So? You want to have some changea made to this PR?

[jnyrup]

Yes, I would like to have a check that the Subject type is not a valuetype or an interface or throw an InvalidOperationException with a descriptive message.

This is similar to what we do in ActionAssertions.FailIfSubjectIsAsyncVoid, XDocumentAssertions.HaveRoot and XDocumentAssertions.HaveElement

Calling typeof(StructType).IsSealed returns true, but that is from a CLR perspective.
The purpose of the type assertions seems to be from a C# perspective, i.e. if the type under assertion has the sealed keyword.

[melchiork]

@jnyrup @dennisdoomen
Done, I've also check if the type is a Delegate.
I went with ArgumentException as similar was done in TypeAssertions.Implement and TypeAssertions.NotImplement

[jnyrup]

BeDerivedFrom and the alike uses ArgumentException as they're checking the argument.
As the Subject isn't an argument to the assertion method I prefer InvalidOperationException like in HaveRoot.

I really like your use of Theory tests.
Excellent job!

[melchiork]

@jnyrup Done. Thanks for the reviews!