Single source of truth for `LintKind` colours

**What problem does this solve?**
Currently the mapping from `LintKind` to colour, currently only used when Harper interacts with the web, is duplicated in two TypeScript files:
- `packages/lint-framework/src/lint/lintKindColor.ts`
- `packages/web/src/lib/lintKindColor.ts`

(The two files are identical by the way)

It seems to me the colours should:
1. have a single source of truth
2. should be available to users of `harper-core`, not just web-based ones.

**Proposed Solution**
1. The colours could be part of the `LintKind` enum in `harper-core/src/linting/lint_kind.rs`.
2. Or they could be external to the enum but associated with its elements externally as some kind of map, probably in the same source file.

How to make it available to the TypeScript components is a more important question to answer. I can think of two ways:
1. Generate the two `lintKindColor.ts` files as part of the build process.
2. Provide some kind of API or APIs through which the TypeScript code can fetch the entire mapping of `LintKind`s to colours, or fetch the specific colour for a given `LintKind`.

At the moment the TypeScript code defines the most efficient way possible as a const literal:
```ts
const LINT_KIND_COLORS = {
Agreement: '#228B22', // Forest green
...
} as const;
```

I'm not sure how essential that is. Naive implementations of an API to fetch the colours not be as efficient. Generating the TypeScript files at build time would maintain the efficiency. Non-naive implementations of an API would fall somewhere between.

I played with a few ways to implement an API a few weeks ago and found it quite a bit more cumbersome than I expected. Somebody more skilled at Rust than me can surely do better.

**Examples**
Here's what I was playing with, to use the colours in a summary when linting on the commandline. But I'm sure there would be many uses for people making tools that use `harper-core` or `harper.js`

**Component**
- [x] Core engine
- [x] Plugin/Extension
- [ ] Other: _____