Refactor sizing logic

[SKProCH]

After 3.0.0 i think that we actually need to change our sizing logic.

Two main goals:

• Allow users to restore 2.x.x behavior (probably on demaid)

• Fix various sizing bugs:

• IconSize wrong sizing #66

• 2.4.x -> 3.0.0 icons is bigger #68 (comment)

This PR changes the measure logic (for now).

Main point: add Stretch and StretchDirection property to allow direct viewbox behavior customizing from user perspective.
Also, return explicit 24/24 size to Path in layout, since all icons (at least if i get it correctly, designed with 24px in mind. If there was an empty space - it should be kept as is)

Defaults:
Stretch - Uniform (preserves aspect ratio)
StretchDirection - DownOnly

I've setup a basic constraints (NEED TO DISCUSS, open to suggestions) (path == viewbox):

• Width/Height drives the resulting control size. Padding shrinks actual path
• IconSize defines resulting PATH size, padding will extend the control bounds over IconSize (Bounds == IconSize + Padding)
  this is done to keep sane FontSize behavior
• If IconSize isn't set, use FontSize, (Bounds == FontSize + Padding)
  (cuz we sizing icon according to the FontSize, and user sets the Padding, i guess user wants padding be not shrink the icon)
  ^ NEEDS DISCUSSION
• When using FontSize, and when MaterialIcon dont have enough space, then control should be shrink down (i guess)?
  ^ NEEDS DISCUSSION

@sn4k3

[SKProCH]

Current sizing:

To implement:

• IconSize doesn't work properly when we have less space then needed (i guess it shouldn't shrink) (row 6)
• IconSize should setup the proper control bounds, now it just fills the entire space (or it shouldn't?)
• Padding + IconSize don't sized as expected
• Double check exact sizes from IconSize wrong sizing #66
• Comparison with a 2.x.x implementation and sizing

[sn4k3]

This PR still have small fixes that should be merged

[SKProCH]

What did you mean?

[sn4k3]

What did you mean?

[SKProCH]

Done