fix(cpp1): apply memberwise semantics to base assignment

[JohelEGP]

Resolves #402 (specifically, #402 (comment)).

Testing summary:

100% tests passed, 0 tests failed out of 684

Total Test time (real) = 113.44 sec

Acknowledgements:

• Tested thanks to https://github.com/modern-cmake/cppfront.
• The commit message uses Conventional Commits 1.0.0.

[JohelEGP]

Without this,
a base type like std::function_ref<T> can't be assigned to.
It's only copy-assignable,
and has a deleted operator=(T):

    constexpr function_ref(const function_ref&) noexcept = default;
    constexpr function_ref& operator=(const function_ref&) noexcept = default;
    template<class T> function_ref& operator=(T) = delete;

Cppfront (main branch) would end up choosing the deleted overload.
With this PR, this would work just fine.

[JohelEGP]

Turns out that the deleted operator=(T) above
is constrained such that T isn't function_ref.
So you could say that
this PR is not needed,
Cppfront (main branch) is OK as is,
and the onus is on the type author to constrain their templated assignments well.

[JohelEGP]

Actually, I don't think that's a valid argument against this PR.
Those templates are usually constrained such that T isn't the base type or a specialization of its template.
They are not constrained such that T isn't derived from a specialization of the base template.
So without this PR, those templates would always attempt to use the derived object.

Here I try constraining the assignment of the code in the to-be-resolved issue (and failed):
https://cpp2.godbolt.org/z/xb77dnqPf (without #486, I had to start from the generated code).
That should be the essence of what std::variant and std::optional do,
but those actually work, so I must be missing something: https://cpp2.godbolt.org/z/Ybq76YWa4.

[hsutter]

Looks good, thank you!