Improved handling of custom services

[donaldgray]

To date iiif-net just maps the data that it's given to concrete POCOs.

However, there are example manifests that contain services that we can't yet map. ExternalService is a fallback for unknown IService items but this will only map properties on the POCO, there are examples where there are new properties. An example is from https://fromthepage.com/iiif/52425/manifest:

"service": [{
  "@context": "http://www.fromthepage.org/jsonld/1/context.json",
  "@id": "https://fromthepage.com/iiif/52425/status",
  "label": "Work Status",
  "profile": "https://github.com/benwbrum/fromthepage/wiki/FromThePage-Support-for-the-IIIF-Presentation-API-and-Web-Annotations#service",
  "pctComplete": 33.34,
  "pctTranscribed": 33.34,
  "pctOcrCorrected": 0,
  "pctIndexed": 1.25,
  "pctMarkedBlank": 1.25,
  "pctNeedsReview": 0,
  "pctTranslationComplete": 1.25,
  "pctTranslated": 1.25,
  "pctTranslationNeedsReview": 0,
  "pctTranslationIndexed": 1.25,
  "pctTranslationMarkedBlank": 1.25,
  "metadataStatus": "undescribed",
  "lastUpdated": "2024-09-05 21:34:18 UTC"
}],

How can we map these properties? Use dynamic? Or a Dictionary<string, object>? Or a JObject? With each of these approaches - how would that look when constructing a service in code, rather than just deserializing.

Should we be more JSON-LD aware and consult @context before deserializing?

[donaldgray]

JSON-LD mentioned in description, dropping https://dotnetrdf.org/ for possible consideration.