fix: behaviors of fit-to-height and fit-to-width

[enklht]

This PR addresses the behaviors of the fit-to-height and fit-to-width functions, resolving issues related to #109.

Changes

1. Changed to use the width and height parameters of measure: Replaced previous hacks using hidden labels with measure's width and height parameters to accurately determine relative sizes within a container.
2. Removed nested box for scale: Eliminated the need for a nested box to handle the size of the scale by utilizing the reflow parameter of scale.
3. Updated examples in the comment: The actual size of 1fr is determined by other frs in the same container, so only one 0.5fr in the container is equivalent to 100%. To avoid this confusion, I slightly changed the documented examples to use % instead.

Notes

• In simple theme, the headings are rendered in slide preamble instead of in the header. This causes relative sizes in simple-theme to appear larger than expected.

---

Please review the changes, particularly the updated example and the new implementation using measure. Any feedback is welcome!

[OrangeX4]

It seems that the current method does not solve the problem #109. What I am thinking is whether we can make the following code work properly (both lorems are contained on the same page):

#import "@preview/touying:0.5.3": *
#import themes.simple: *

#show: simple-theme.with(aspect-ratio: "16-9")

= Title

== First Slide

#utils.fit-to-remaining-height[#lorem(50)]

#lorem(50)

It seems that this PR does not solve this problem at present, even using #utils.fit-to-height(100%)[#lorem(50)].

Maybe we can find inspiration here: https://forum.typst.app/t/how-to-auto-size-text-and-images/1290

[enklht]

I apologize for the misunderstanding regarding the function's purpose.
I initially thought it was meant to adjust the content size to fit within the outer container's dimensions, rather than using the remaining space. And at least, new implementation resolves the problem that the function makes only an empty space, as explained in #109

[OrangeX4]

Thanks. Yes it solves part of the problem, I just thought maybe there is a way to solve all of it. Maybe we still need to think about it.

[enklht]

By the way, have you tried the new fit-to-height function with a small percentage parameter, like 25%? I think this is the intended behavior in the example of issue #109. Since the parameter-free function is currently too complex, it makes sense to close the bug-fix issue and open a new one for fit-to-remaining-height. What do you think?