`IsCompatible`: Check `MemberAccessor` against expected `Topic`

[JeremyCaney]

Currently, in the TopicMappingService, both TryGetCompatibleProperty() and GetScalarValue() rely on reflection to determine if there's a corresponding member on the source Topic that's compatible or, at least, convertible to the model property. As we're already preloading and caching reflection data via MemberAccessor, we should be able to apply a heuristic for determining if such a compatible match is likely.

This evaluation cannot be 100% accurate since it doesn't know the source Topic type. Since neither the framework nor implementers commonly subclass Topic, however, this isn't expected to be a concern. Further, we can attempt to identify the most likely Topic subclass, if available, by inferring the content type from the model name (based on the {ContentType}[Topic]ViewModel convention).

For efficiency purposes, it's likely best to evaluate this as part of the TypeAccessor, and then set the values on each MemberAccessor and ParameterMetadata. Otherwise, the corresponding Topic must be identified for each member, and its members enumerated. It's better to do this once, ideally as part of the TypeAccessor constructor.

[JeremyCaney]

The previous commits were merged into develop as part of c718adc0, thus completing this improvement. This includes adding the MaybeCompatible property to ItemMetadata (6662e18), setting it via the TypeAccessor constructor (359eaae), and integrating that into the TopicMappingService (1e2dc53). In addition, the MaybeCompatible was also integrated into the AttributeDictionary constructor threshold (3a6820b1), providing a more intelligent way of evaluating whether attributes were likely to be utilized. Finally, a unit test was added to validate that MaybeCompatible is being correctly set on parameters and members (fabeb82).