More information and structure is desirable in JSON output

[TomMD]

One file entry of JSON output looks like so:

  [
      "src/Stan/Hie.hs",
      {
        "cabalExtensions": [
          "ConstraintKinds",
          "DeriveGeneric",
          "DerivingStrategies",
          "GeneralizedNewtypeDeriving",
          "InstanceSigs",
          "KindSignatures",
          "LambdaCase",
          "OverloadedStrings",
          "RecordWildCards",
          "ScopedTypeVariables",
          "StandaloneDeriving",
          "TupleSections",
          "TypeApplications",
          "ViewPatterns"
        ],
        "extensions": [],
        "loc": 102,
        "moduleName": "Stan.Hie",
        "observations": [
          {
            "file": "src/Stan/Hie.hs",
            "id": "OBS-STAN-0103-W93KYS-64:32",
            "inspectionId": "STAN-0103",
            "loc": "\"src/Stan/Hie.hs\"(64:32-64:38)",
            "moduleName": "Stan.Hie"
          }
        ],
        "path": "src/Stan/Hie.hs"
      }
    ]

This is really rich, but I am hoping to get a few additional fields to make external tools' lives easier.

1. An observation description field with inspectionDescription contents.
2. An observation name from inspectionName
3. At least start line if not both start and end lines, that is srcLocLine (realSrcSpanStart observationLoc).

The first two are new information. It seems with the current information each consumer would need to have the mapping of inspectionId to inspection text in order to make use of the JSON.

The final one is indeed redundant, but if we're outputting JSON then making consumers parse another, non-standard, format doesn't fit the spirit of machine parsable.

Thoughts? Would a PR be acceptable.

Also huge thanks to @vrom911 for finding a threading of the needle that satisfies both competing asks from the prior ticket of JSON and low dependency overhead.

[TomMD]

In addition, we should consider a flag or default of making the description markdown or otherwise render-friendly. The current system seems to have the code inline with the issue text which makes highlighting hard.

[chshersh]

1. An observation description field with inspectionDescription contents.
2. An observation name from inspectionName

This information is already present in JSON. We output the list of all inspections used in the code, so you can easily get these pieces of data. Changing ToJSON instances for our types to add redundant information will complicate Stan design and prevent implementation of future features from our roadmap.

[TomMD]

This information is already present in JSON.

Great, I didn't see that. Now we're down to getting spans in a JSON form (number 3).