Fix confusing weakref constructor overload

[YannickJadoul]

Description

Fixes #2536, where the two weakref constructors from handle and object do different things.
Demonstrated by failing tests in the first commit, fixed in the second one.

Suggested changelog entry:

Fix the ``weakref`` constructor from ``py::object`` to create a new ``weakref`` on conversion.

[rwgk]

Looks good to me. I'll globally test this (without the default constructor) to see if anyone is relying on it, mostly out of interest. Preserving the default constructor seems best irrespectively.

[rwgk]

Google-global testing this as-is (without the default constructor) came back green. Might be nice to add something along the lines of "very unlikely to be useful but supplied for backward compatibility" in a comment when you put back the default constructor.

[YannickJadoul]

Might be nice to add something along the lines of "very unlikely to be useful but supplied for backward compatibility" in a comment when you put back the default constructor.

If we want to do that, I think we should go with an official deprecation, but I'm fine just being fully backward compatible and pushing the "let's make all py::object subclasses consistent" into the future.

[YannickJadoul]

you put back the default constructor.

I added PYBIND11_OBJECT_CVT_DEFAULT to make clear that this is part of the whole PYBIND11_OBJECT* macro zoo. This groups things if we ever were to e.g. deprecate the default contructors of py::object subclasses, in some hypothetical future.

[YannickJadoul]

I think we went over all bits and pieces, then :-) Let's close another PR and issue.

Thanks, all!