Add a trait for the `Val` helper functions to allow the input of multiple types

[TheBlckbird]

What problem does this solve or what need does it fill?

As discussed in #15937 and #20518, we could add a trait for the new helper functions to allow them to accept multiple types.

This would make the code look cleaner, because you could use i32 and f32 instead of writing px(10.), for example.

What solution would you like?

Add a trait AsValNum that with a method that converts something to a float:

pub trait ToValNum {
    fn to_val_num(self) -> f32;
}

impl ToValNum for f32 {
    fn to_val_num(self) -> f32 {
        self
    }
}

impl ToValNum for i32 {
    fn to_val_num(self) -> f32 {
        self as f32
    }
}

pub fn px<T: ToValNum>(n: T) -> Val {
    Val::Px(n.to_val_num())
}

Open decisions to be made:

• Final decision: Is this what we want (although @cart already said yes?, just putting this in here again)?
• For which types do we implement this? All integer types? I think, that would make the most sense

What alternative(s) have you considered?

Casting to f32 all the time.

Additional context

Even though the decision whether we want to implement this seems to have already been made, I'm just moving the design discussion to this issue.

[TheBlckbird]

One drawback would be, that the helper functions couldn't be declared as const anymore

[rendaoer]

trait NumToVal {
    fn px(self) -> Val;

    fn percent(self) -> Val;
}

impl NumToVal for i32 {
    fn px(self) -> Val {
        Val::Px(self as f32)
    }

    fn percent(self) -> Val {
        Val::Percent(self as f32)
    }
}

impl NumToVal for f32 {
    fn px(self) -> Val {
        Val::Px(self)
    }

    fn percent(self) -> Val {
        Val::Percent(self)
    }
}

Wouldn't it be better to just use 1.px()?

[TheBlckbird]

The problem with that wuold be, that every number would have the .px() method: #15825 (comment)

I think, we should stick to the helper functions, especially because that decsion was already made a few months ago.

Edit: Just to make it clear, I'm not against that idea, but I do see the downsides of it being available in the autocomplete everywhere.

[TheBlckbird]

Example

// Functions
px(10)
percent(20.5)
vh(19)

// Methods
10.px()
20.5.percent()
19.vh()

Hm, now I really don't know, which of these is the better solution anymore.

Pro for method syntax:

• It is more aligned with what you'd usually write: first number, then unit (10px, 20.5%)

Contra for method syntax:

• 20.5.percent() looks a bit confusing (too many dots)
• Using a method kind of conveys the meaning of transforming the number
• the methods will always be available in the autocomplete
• Numbers are literals, they shouldn't be treated as objects in this case (well, theoretically)

Pro for function syntax:

• Looks very natural/intuitive. This would be the first thing, someone thinks of
• The meaning of a number stays the same, it doesn't immediately look like it's being transformed

Contra for function syntax:

• The order of number and unit is reversed; might make it seem a bit less natural

But regarding the comment from cart I just linked above, I think we should just stick to the function syntax and finalize and merge the linked PR.