Use new xproperty

[Hind-M]

cf. jupyter-xeus/xproperty#71

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[Hind-M]

NOTE:

In the xwidgets.ipynb notebook example:

#include <xwidgets/xbutton.hpp>

auto bt = xw::button::initialize()
    .description("button")
    .finalize();

bt.on_click([](){
    bt.description = "Clicked!";
    bt.button_style = "success";
});
    
xcpp::display(bt);

There was a bug where finalize() with a rvalue forced a copy of the widget. This resulted in the loss of registered validators for the new object.

In the case of xbutton, the following validator:

template <typename... T>
auto XEITHER(T... vals)
{
    const std::unordered_set<std::string> options({vals...});
    return [options](const auto& proposal)
    {
        auto position = options.find(proposal);
        if (position == options.end())
        {
            throw std::runtime_error("Invalid proposal for string enum");
        }
    };
}

used here:

XPROPERTY(
    std::string,
    xcommon,
    button_style,
    "",
    XEITHER("primary", "success", "info", "warning", "danger", "")
);

was not being triggered in the subsequent cell:

try {
    bt.button_style = "some invalid value";  // values are validated upon assignment
}
catch(std::exception const& btn_exception)
{
    std::cerr << btn_exception.what();
}

This was supposed to catch the thrown exception and print:
Invalid proposal for string enum, but that wasn't the case as nothing was printed and the following code cell:

std::cout << bt.button_style();

printed the invalid value which shouldn't be set in the first place: some invalid value.

This is fixed in this PR as the exception message is printed now and the value of bt.button_style() remains unchanged (the default empty string), meaning that the invalid assignment was correctly blocked.

[JohanMabille]

Now that the chaining syntax is not available anymore, I think we shoujld keep overloads for both lvalue and rvalue references. Maybe we can simply have a singel finalize method. Even if we find a nicer initialization syntax, it won't be based on chaining move constructor since the xproperty does not know its owner type anymore.

[JohanMabille]

Actually having a single finalize method working for all kinds of reference would break the following:

auto w = std::move(my_widget).finalize();

Although this code is weird and unlikely to happen, we should opt for the less surprise principle. So let's keep bothe overloads for now, ignore my previous comment.