Add support for TS 4.5 import type modifiers

[alangpierce]

Fixes #668

Details on the syntax are described here:
https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#type-on-import-names

This was implemented in Babel here: babel/babel#13802

In terms of behavior, the type syntax is almost a no-op in valid code; we
already scan the file to see which identifiers have been used in a value or type
context and remove type imports automatically, and this PR doesn't change that.
However, there are a few subtle differences:

• When targeting commonjs, if an imported name has a type modifier and is used
  in a value context, we do not transform the syntax to access the module like
  we did before. For example, this comes up if accessing a global value with the
  same name as an imported type.
• In both CJS and ESM targets, code that imports and then re-exports a type
  needs to have that export elided. Previously, this was a situation where TS
  doesn't know whether the name is a type or not, so it included the export as a
  value.

Right now, there is no equivalent to --preserveValueImports, but this could be
added in the future. It almost would turn the TS transform into a purely
syntax-level transform without the need for scope analysis and variable name
tracking (thus simplifying and speeding up Sucrase if it became the standard
approach), except that even with that flag set, type-only exports are still
elided.

In terms of implementation details, the Babel parser details were a bit
AST-focused and didn't need to deal with IdentifierRoles, so I re-implemented
parsing using a simpler approach, which was also useful in the transform step.

It turns out that in both Flow and TS, you can parse an import or export
specifier by accepting anywhere from 1 to 4 identifiers, and the number of
identifiers is enough to exactly determine the syntax. This is more reliable
than matching on the names type (or typeof) and as because those are
contextual keywords that might be valid identifiers.

In the transform step, there were 5 places where we were manually walking
import/export specifiers, so it seemed best to unify that parsing into a shared
utility. This potentially has some performance cost due to the object
allocations, but it's likely to be very minor and could potentially be improved
later.

[codecov]

Codecov Report

Merging #713 (4a9ecb2) into main (ee5879e) will increase coverage by 0.16%.
The diff coverage is 98.01%.

@@            Coverage Diff             @@
##             main     #713      +/-   ##
==========================================
+ Coverage   85.36%   85.53%   +0.16%     
==========================================
  Files          54       55       +1     
  Lines        5855     5882      +27     
  Branches     1337     1331       -6     
==========================================
+ Hits         4998     5031      +33     
+ Misses        576      574       -2     
+ Partials      281      277       -4     

Impacted Files	Coverage Δ
src/util/getImportExportSpecifierInfo.ts	89.47% <89.47%> (ø)
src/CJSImportProcessor.ts	91.91% <100.00%> (-0.36%)	⬇️
src/parser/plugins/typescript.ts	86.11% <100.00%> (+0.82%)	⬆️
src/parser/traverser/statement.ts	82.85% <100.00%> (+0.20%)	⬆️
src/transformers/CJSImportTransformer.ts	88.32% <100.00%> (-0.03%)	⬇️
src/transformers/ESMImportTransformer.ts	90.07% <100.00%> (+2.93%)	⬆️
src/util/getTSImportedNames.ts	84.21% <100.00%> (-1.16%)	⬇️

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[github-actions]

Benchmark results

Before this PR: 330.2 thousand lines per second
After this PR: 329.7 thousand lines per second

Measured change: 0.16% slower (0.79% slower to 0.82% faster)
Summary: Likely no significant difference