Strawberry-graphql

-------------------

Internal refactoring.

* Renamed `StrawberryArgument` to `StrawberryArgumentAnnotation`
* Renamed `ArgumentDefinition` to `StrawberryArgument`
* Renamed `ArgumentDefinition(type: ...)` argument to
`StrawberryArgument(type_: ...)`

-------------------

Fixed issue with django multipart/form-data uploads

-------------------

Fix issue where StrawberryField.graphql_name would always be camelCased

-------------------

This release fixes an issue with the generated `__eq__` and `__repr__` methods when defining
fields with resolvers.

This now works properly:

python
strawberry.type
class Query:
a: int

strawberry.field
def name(self) -> str:
return "A"


assert Query(1) == Query(1)
assert Query(1) != Query(2)

-------------------

Gracefully handle user-induced subscription errors.

-------------------

* `FieldDefinition` has been absorbed into `StrawberryField` and now no longer exists.

* `FieldDefinition.origin_name` and `FieldDefinition.name` have been replaced with
`StrawberryField.python_name` and `StrawberryField.graphql_name`. This should help
alleviate some backend confusion about which should be used for certain situations.

* `strawberry.types.type_resolver.resolve_type` has been split into
`resolve_type_argument` and `_resolve_type` (for arguments) until `StrawberryType` is
implemented to combine them back together. This was done to reduce the scope of this
PR and defer changing `ArgumentDefinition` (future `StrawberryArgument`) until a
different PR.

> Note: The constructor signature for `StrawberryField` has `type_` as an argument
> instead of `type` as was the case for `FieldDefinition`. This is done to prevent
> shadowing of builtins.

> Note: `StrawberryField.name` still exists because of the way dataclass `Field`s
work, but is an alias for `StrawberryField.python_name`.