Support automatic `__new__` generation in `#[pyclass]` with `set_all`

Currently, if the developer does not provide a #[new] method for a class, the object can only be constructed in Rust land. However, if a struct derives #[pyclass(set_all)], there can also be a default constructor that implements __new__ using all the attributes of the struct.

Example:

#[pyclass(set_all, auto_new)]
struct Foo {
    bar: u64,
    baz: String
}

// auto_new would generate the following
#[pymethods]
impl Foo {
    #[new]
    fn pyo3_new(bar: u64, baz: String) -> Self {
        Self {
            bar,
            baz
        }
    }
}

Since set_all already requires all the fields to implement IntoPyObject, arguments for method shouldnt have any issue, even in the case of classes as parameters. Only issue I see is that it would require the multiple-pymethods feature, since this would be a block on its own.

Personal use-case - I am writing a library that exposes a bunch of structs generated from proto files, and I want to expose them to python land, including constructors.

I am happy to work on this, unless I am missing something it should be another field to PyClassPyO3Options in pyo3-macros-backend and then add some code to pyclass.rs impl_class(), but would also appreciate pointers.

Also open to bikeshedding around the auto_new name.

Start in pyo3-macros-backend at PyClassPyO3Options and follow pyclass.rs impl_class(), then examine how the multiple-pymethods feature structures generated methods. Implement the opt-in automatic new behavior for #[pyclass(set_all)] using all struct attributes, and confirm the generated constructor exposes those fields to Python.