Issue title: License check is very slow
 Issue body: `setup-cfg-fmt` takes about 11 seconds on my system, at least if it doesn't find any exact matches for the license text so has to scan all the way through the list.  This makes it awkward to use as a fast lint check.  Most of the time is spent in `identify.identify.license_id`, specifically in normalizing each of the vendored license texts in turn, before getting to the `editdistance_s.distance` call.

Is there anything that could be done to speed this up?  One thing I thought of as a possibility would be to pre-normalize all the license texts in `bin/vendor-licenses`, though of course that would make the vendored list rather less readable; I don't know if you care about that.
 Comments: 
 Comment 0: [please provide more information, as written your issue does not have enough information to reproduce your problem](https://youtu.be/ritp4gAqNMI)

do you have a reproduction? the normalization is pretty fast in my experience and only in the slowest cases does it invoke editdistance (which yes is kinda slow)
 Comment 1: ```
$ git clone https://git.launchpad.net/lpcraft
$ cd lpcraft
$ git checkout be42b4bca4de7a20dff462a9808c9001f2dc9a9f
$ time pre-commit run -a setup-cfg-fmt
setup-cfg-fmt............................................................Passed

real    0m11.336s
user    0m11.110s
sys     0m0.063s
```

Re `editdistance`, the problem seems to be not that `editdistance` is slow, but that all the license normalization run prior to calling `editdistance` is slow.  (Though I only verified that by playing around a bit in `pdb`.)
 Comment 2: from some timing, `a` surrounds the first normalize, `b` surrounds the second normalize, `c` surrounds a call to editdistance:

```console
$ python3 -c '__import__("identify.identify", fromlist=[""]).license_id("LICENSE")'
a 5300.135286681
a 5300.139472585
5300.139493705
b 5300.139502921
b 5300.139584077
b 5300.139597776
b 5300.140830073
b 5300.140850212
b 5300.145079131
c 5300.145101515
c 5302.819639074
b 5302.819668104
b 5302.820955211
b 5302.820970365
b 5302.822005245
b 5302.82201823
b 5302.822183949
b 5302.822195219
b 5302.82236819
b 5302.822375717
b 5302.822569369
b 5302.822576987
b 5302.822796009
b 5302.822807929
b 5302.825086277
b 5302.825100205
b 5302.827564378
b 5302.827577856
b 5302.828331206
b 5302.828343024
b 5302.829570874
b 5302.829582495
b 5302.830998409
b 5302.83102393
b 5302.832524817
b 5302.832536411
b 5302.834068735
b 5302.834081334
b 5302.835751277
b 5302.835763453
b 5302.837819487
b 5302.83783182
b 5302.84175405
c 5302.841766469
c 5305.557236993
b 5305.557268292
b 5305.557359694
b 5305.557367958
b 5305.560557374
b 5305.56057168
b 5305.561463407
b 5305.561475739
b 5305.56366881
b 5305.563681302
b 5305.563823152
b 5305.563834044
b 5305.565677653
b 5305.565689917
b 5305.56599999
b 5305.566007909
b 5305.566374694
b 5305.566385917
b 5305.56656289
b 5305.566570562
b 5305.567032755
b 5305.567040818
b 5305.568251948
b 5305.568264823
b 5305.568373669
b 5305.568381489
b 5305.56860484
b 5305.568609823
b 5305.568754588
b 5305.568759158
b 5305.568816997
b 5305.568821273
b 5305.568923915
5305.568932102
```

the process overall takes 5.5 seconds, and is dominated by the two `editdistance` checks (2.7s, 2.7s)

so your assessment is not correct
 Comment 3: one idea to speed up the edit distance is implement an Ukkonen threshold variant of the algorithm which runs in much faster space/time
 Comment 4: Ah, in that case my apologies for misdiagnosing!
 Comment 5: good-ish news, I played around with some alternate algorithms and it looks like we can drastically improve this -- but need to do some stuff to make it correct
 Comment 6: Confirmed - thanks a lot!
{'source': 'GithubIssues', 'repo_name_with_owner': 'pre-commit/identify', 'issue_id': 1055113702, 'repo_stars': 113.0}