Preload `TopicPayload` as part of `MapAsync()`

[JeremyCaney]

When the TopicMappingService converts a topic entity into a view model, the lazy-loading implementation fetches any necessary data piecemeal: One small database round-trip per property, discovered only as each property is mapped. This fixes that by analyzing each view model type once, up front, to determine exactly what data it needs, then fetches all of it in a single consolidated request at the start of the conversion instead of triggering multiple requests as it goes. It then caches that payload so it doesn't need to analyze the same view model every request.

Tasks

• Add concurrency infrastructure (coalescing, per-topic serialization) so multiple loads for the same topic can't race or duplicate work (Topic.EnsureLoaded()); see Mapping Services Lazy-Loading Integration #118
• Add a [RequiresPayload] attribute so a view model can declare its data needs explicitly, bypassing analysis (new type in OnTopic.Mapping.Annotations)
• Build a cached, per-type analyzer that determines what payload a given view model needs (new MappingPayloadProfile)
• Fire one consolidated EnsureLoaded() request at the top of each MapAsync() conversion, before property mapping (TopicMappingService)
• Annotate the library's view models so they don't over-fetch (e.g., NavigationTopicViewModel in OnTopic.ViewModels)
• Parallelize the loading of multiple deferred relationships and references instead of loading them one at a time (LazyLoadingTopicRepository.ResolveDeferredAssociations()); see Batch load Deferred associations #127
• Apply the above to the other mappers to the Nested-topic and tree flattening
  • See TopicMappingService.FlattenTopicGraph, PopulateTargetCollectionAsync()
• Narrow relationship and reference loading to only the specific keys a given view model maps
  • See Topic.EnsureLoaded(), ITopicLoadResolver.EnsureLoaded()
• Create unit tests to validate the above logic