refactor(graphql): GraphQL Public API Refactor + Documentation

[jjoyce0510]

This PR refactors the GraphQL API mainly addressing conventional consistency concerns. It also adds a bunch of new GraphQL API documentation! Rendered:

• Overview
• Getting Started
• Querying Metadata Entities

Also introduced auto-generated GraphQL Schema Reference documentation. These files are not checked in, but instead generated at build time.

Changes

• Split monolithic GraphQL model file into 3 sub-schemas
  - entity.graphql: all CRUD operations against a given entity type (create, update, get, list)
  - search.graphql: all search and browse related graphql models
  - app.graphql: all UI specific graphql models (e.g. appConfig)
• Added model descriptions for all GraphQL types and fields
• Deprecate misc Entity "info" fields for standardized "properties" and "editableProperties" fields
• Consistently accept urn, input arguments for each Update mutation to facilitate reuse of the Update input model in "create" APIs that will be coming soon.
• Migrate "relationships" field input arguments to single wrapper "input" object, aligning with conventions across the app
• Add Dataset "properties" field, deprecate root-level property fields (ie. description)
• Miscellaneous renaming of models for consistency
  - TagUpdateInput -> TagAssociationInput
  - TermUpdateInput -> TermAssociationInput
  - TagUpdate -> TagUpdateInput
  - PolicyUpdate -> PolicyUpdateInput
  Breaking GraphQL API changes:
• Remove the legacy string "tags" field from Dataset model
• Migrate custom properties for Dataset from root level "properties" field to new properties.customProperties to align with other entity convention
• Added GraphQL API Documentation generation + added to documentation website

Validated all changes locally.

Coming soon

• Rich GraphQL Documentation on docs website
• addOwner, removeOwner mutations
• listEntity endpoints
• createEntity, removeEntity endpoints
• Consolidation in root-level key fields (urn, entity type, platform, name)
  Let us know which you'd like to see on our Slack :)

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable)

[gabe-lyons]

why not just do a single > and drop the rm?

[gabe-lyons]

just consistency w/ the lines below?

[shirshanka]

We finally have a public API! Really excited to see how the community responds.