Add /intents and /contexts endpoints to the AppD API

## Enhancement Request

When working with an app directory it would be useful to be able to request the list intents and contexts used by apps listed in the app directory. This information is already retrievable, to a certain extent, from the individual records, however, doing so requires interesting all the records and collecting up the information.

Adding intent and context endpoints to the API would allow:
- Pre-population of search/browsing interfaces for filtering apps by supported intents and contexts
- Note the underlying data for such searches may be significantly improved by #247
- The use of these endpoints to provide display data (e.g. displayName)
- There is a long-standing issue with intents in that each app may configure a different display name for the same intent: #312

Proposed endpoints:
| route | REST verb | Description |
|---------------------------------------|------|--------------|
| /v2/intents | GET | Retrieve a list intent supported in the app directory instance |
| /v2/intents/{intent name} | GET | Retrieve detail on a particular intent |
| /v2/contexts | GET | Retrieve a list of contexts referenced in the app directory instance |
| /v2/contexts/{context type name} | GET | Retrieve detail on a particular context |

The detail endpoints for an individual intent and context types could:
- Be replaced by returning all the detail under the main endpoints
- Provide a list of the apps that reference it
- Provide a schema or similar detail for the context (however this could/should be optional as not every implementation will want to provide references for standardized contexts)

A number of AppD implementations already provide these endpoints, including electron-fdc3 and the AppD browser demoed to the group by Citi.

It has also been proposed in the past that it is necessary to provide tools to govern internal/proprietary intents and contexts and that this has been implemented in the past through an extension to an app directory implementation. These would be natural extension to the proposed details endpoints.

No files, tests, or entry points are named. Start by locating the AppD API routing and app-directory data model, then review existing intent and context representations in individual records. Done means agreeing on the endpoint response shape and implementing and testing the proposed list and detail routes, including the unresolved detail and schema options.

Written by the indexing model from the issue text.