TabWidget: Add orientation property to TabWidget

[taichi765]

Summary

This PR adds an orientation property to TabWidget (Material style only), allowing the tab bar to be displayed vertically.

Related issue: #3688

Example

TabWidget {
        orientation: Orientation.vertical;
        Tab {

        }
}

Notes

• @children inside if is not yet supproted, so the implementation switches between two internal components at compile time.

export component TabBarImpl inherits TabBarBase {
    Flickable {
        if root.orientation==Orientation.vertical:VerticalLayout {
            @children// The @children placeholder cannot appear in a conditional element
        }
        if root.orientation==Orientation.horizontal:HorizontalLayout{
            @children
        }
    }
}

• Because of this, runtime bindings for orientation are not supported.
  For example:

component MyTabs {
    in property <Orientation> orientation;

    TabWidget {
        orientation: root.orientation;// this will be ignored
    }
}

Questions

• Is the compile-time switching approach acceptable for now?
• Is there a better way to implement vertical tabbar?

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

Thanks for opening a PR.

I think this is a feature we should have.

Is the compile-time switching approach acceptable for now?

I'd say so, yes.

Is there a better way to implement vertical tabbar?

I'm afraid all the other ways would required change that would be more complicated (but that we probably still want)
Either:

1. Add a OrientedLayout that has an orientation argument at runtime (name to be bikeshedded)
2. Use a GridLayout and have the compiler set the row/col for the individual tab
3. Not use a XXXLayout in TabBarImpl, but have the lower_tabwidget pass have the equivalent of a OrientedLayout despite that wouldn't be in the Slint language.

(Supporting @children in if would have the problem that it wouldn't be possible to reference the item anymore, unless we use other trick like a switch or something where we have @children on each branch or have a more complex language feature which is out of scope for this)

So thinking of it, the OrientedLayout seems to be the easier, and it could even be kept internal.
But as I said, I think it is fine to keep it compile-time constant for now.

Btw, if making it a const expression, we should also forbid assignement like so:

slint/internal/compiler/typeregister.rs

Lines 494 to 495 in 65fb303

	popup.properties.get_mut("close-policy").unwrap().property_visibility =
	PropertyVisibility::Constexpr;

and make it an error when it is not specified at compile time.

[taichi765]

Thanks for the advice!
I've added it.

Remaining tasks:

• Update Cosmic tabwidget
• Update Cupertino tabwidget
• Update Fluent tabwidget
• Update Qt tabwidget
• Write test

Is there anything else?