## Summary

Follow-up from #18401, I was looking at whether that would fix the issue
at astral-sh/ty#247 (comment)
and it didn't, which made me realize that the PR only inferred `list[T]`
when the value type was tuple but it could be other types as well.

This PR fixes the actual issue by inferring `list[T]` for the non-tuple
type case.

## Test Plan

Add test cases for starred expression involved with non-tuple type. I
also added a few test cases for list type and list literal.

I also verified that the example in the linked issue comment works:
```py
def _(line: str):
    a, b, *c = line.split(maxsplit=2)
    c.pop()
```

…aration

* origin/main:
  [ty] Infer `list[T]` when unpacking non-tuple type (#18438)
  [ty] Meta-type of type variables should be type[..] (#18439)
  [`pyupgrade`] Make fix unsafe if it deletes comments (`UP050`) (#18390)
  [`pyupgrade`] Make fix unsafe if it deletes comments (`UP004`) (#18393)
  [ty] Support using legacy typing aliases for generic classes in type annotations (#18404)
  Use ty's completions in playground (#18425)
  Update editor setup docs about Neovim and Vim (#18324)
  Update NPM Development dependencies (#18423)
  Infer `list[T]` for starred target in unpacking (#18401)
  [`refurb`] Mark `FURB180` fix unsafe when class has bases (#18149)
  [`fastapi`] Avoid false positive for class dependencies (`FAST003`) (#18271)