feat(eslint-plugin): added new rule use-default-type-parameter

[JoshuaKGoldberg]

Adds the equivalent of TSLint's use-default-type-parameter rule.

I'm not sure what to do about the lack of test coverage on the files, since most of them are for edge cases in the TypeScript API not finding information. Would you prefer nodes of unknown types be added as test cases? Will wait for further instructions...

[codecov]

Codecov Report

Merging #562 into master will decrease coverage by 0.02%.
The diff coverage is 92.45%.

@@            Coverage Diff             @@
##           master     #562      +/-   ##
==========================================
- Coverage   94.34%   94.31%   -0.03%     
==========================================
  Files         111      112       +1     
  Lines        4735     4787      +52     
  Branches     1315     1331      +16     
==========================================
+ Hits         4467     4515      +48     
- Misses        156      157       +1     
- Partials      112      115       +3

Impacted Files	Coverage Δ
packages/eslint-plugin/src/util/misc.ts	88% <100%> (+3.78%)	⬆️
packages/eslint-plugin/src/rules/index.ts	100% <100%> (ø)	⬆️
...rc/rules/indent-new-do-not-use/BinarySearchTree.ts	100% <100%> (ø)	⬆️
...-plugin/src/rules/no-unnecessary-type-arguments.ts	91.11% <91.11%> (ø)
.../eslint-plugin/src/rules/no-useless-constructor.ts	100% <0%> (ø)	⬆️

[bradzacher]

LGTM

[bradzacher]

could we just introduce https://github.com/runem/ts-simple-type#readme ?

[JoshuaKGoldberg]

In theory, sure. Would you like me to do this here or in a separate PR?

[JamesHenry]

Thanks a lot for doing this, the implementation LGTM.

However, I can't help feeling this rule should be called no-unnecessary-type-arguments. I think that is subjectively more descriptive of what it enforces, and fits better with the existing conventions for these kinds of rules, both in our plugin and the ESLint ecosystem as a whole.

WDYT?

[JamesHenry]

Thanks @JoshuaKGoldberg! Sorry about the conflict, hopefully it's easy enough to reconcile I've attempted to clean up the conflict via the GitHub UI