Fixes #3178

Problem

Several assertion methods followed this pattern:

assertionChain
    .ForCondition(subject is not null)
    .FailWith("... is <null>.")
    .Then
    .ForCondition(subject.Member)   // eagerly evaluated!
    .FailWith(...);

C# evaluates method arguments before invoking the method, so subject.Member is evaluated even when subject is null and the first condition already failed. Outside of an AssertionScope, the first failure throws immediately, so the chain never reaches the second line. Inside an AssertionScope, failures are only recorded (not thrown), so execution continues to the second .ForCondition(...), and evaluating subject.Member throws a NullReferenceException instead of producing a proper assertion failure message.

Fix

Replaced the eager dereferences with null-conditional comparisons (e.g. subject?.Member == true), following the pattern already used in TimeOnlyAssertions.cs. Also made a failure message in TypeAssertions.HaveProperty lazy, since it referenced propertyInfo.Name even when propertyInfo could be null.

Affected members

• PropertyInfoAssertions: BeVirtual, NotBeVirtual, BeWritable (both overloads), NotBeWritable, BeReadable (both overloads), NotBeReadable, Return, NotReturn
• TypeAssertions: HaveProperty, HaveIndexer

Testing

• Added regression tests that wrap each affected assertion in an AssertionScope, reproducing the exact scenario from the issue.
• Full FluentAssertions.Specs suite passes: 5963/5963 (net8.0).
• Targeted PropertyInfoAssertionSpecs/TypeAssertionSpecs pass on net47, net6.0, and net8.0 (402/402 each).

No public API changes, so no API-approval step is required.