fix: swr infers incorrect data type for default SWRConfig generic type

[connorch]

This PR resolves issue #2505 by reverting PR #2452, and updates the tests to better explain why this issue cannot be fixed: #2396

#2396 suggests that if a generic is passed to the useSWR hook, that the library should still infer the type of the SWRConfig passed in. However, this isn't possible in typescript due to limitations with partial inference. That is, typescript can either infer all generics or none at all - never some but not others.

Here's a simple example to showcase this partial inference limitation:

type Foo = <A = any, B = any, C = any>(a: A, b: B, c: C) => [A, B, C]
const foo: Foo = (a, b, c) => [a, b, c]
const bar1 = foo(1, 2, 3)
//     ^? const bar1: [number, number, number]
const bar2 = foo<number>(1, 2, 3)
//     ^? const bar2: [number, any, any]  - Passing just one explicit generic to `foo` removes type inference for the rest of the generics.

#2452 didn't actually fix the issue #2396 - it just forced it so that the default of the SWRConfig generic forced the type check in BlockingData to always evaluated to true. This is now tested against in the new test case testConfigAsSWRConfiguration. I also updated all of the tests added in that PR to point to some documentation explaining this typescript limitation.

Some other documentation on this issue:
microsoft/TypeScript#26242
https://stackoverflow.com/questions/60377365/typescript-infer-type-of-generic-after-optional-first-generic

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 3e32cfc:

Sandbox	Source
SWR-Basic	Configuration
SWR-States	Configuration
SWR-Infinite	Configuration
SWR-SSR	Configuration

[connorch]

This PR fixes #2505

[promer94]

Thanks for the comments and links !

[connorch]

Thanks for the speedy merge! 🙌