Summary:

In the previous PR, I added basic support for converting an
Assign with a type comment to an AnnAssign, as long as there was
only one target.

This PR handles all fully PEP 484 compliant cases:
- multiple assignments
- multiple elements in the LHS l-value

We cannot handle arity errors because there's no way to do it. And
we don't try to handle the ambiguous case of multiple assignments with
mismatched arities (PEP 484 isn't super clear on which LHS is supposed
to pick up the type, we are conservative here). The ambiguous case is
probably very uncommon in real code anyway, multiple assignment is not
a widely used feature.

NOTE: my local pyre is complaining and I don't understand it, putting
a PR up anyway to see what CI does.

Test Plan:

There are new test cases covering:
- multiple elements in the LHS
- multiple assignment
- both of the above together
- semicolon expansion, which is handled differently in the cases
  where we have to add type declarations
- new error cases:
  - mismatched arity in both directions on one assignment
  - mismatched arity in multiple assignment
```
> python -m unittest libcst.codemod.commands.tests.test_convert_type_comments
.....
----------------------------------------------------------------------
Ran 5 tests in 0.150s

OK
```

There were three different layers of target things, which
meant using target / targets as a naming convention was not
working well.

Now, I say:
- a target is one or more `target` values
- a target is a single lvalue, and maps to a `bindings` object
  of one or more bindings
- a binding is a specific, single value that can be annotated

Similarly, there are two layers in annotation handling:
- a type comment corresponds to an annotations, one or more types
- an annotations atom is an annotation

When zipping, we zip a single bindings against a single annotations.

When handling multi-assignment Assigns, we have to do this multiple
times and concatenate the results.