Add scale_effect modifier

[dginsburg]

Closes #520

@supernintendo @carson-katri @shadowfacts Sorry to spam all of you on this. I'm not sure who is the best person for me to ask questions of. Can I get your thoughts on this approach to the Elixir parameters?

This PR is to implement the scale_effect modifier, which has two signatures.
https://developer.apple.com/documentation/swiftui/view/scaleeffect(_:anchor:)-pmi7
https://developer.apple.com/documentation/swiftui/view/scaleeffect(_:anchor:)-7q7as

I thought we could omit the signature that takes a single param because the version I've implemented that uses width and height can superseed the single param signature. I saw a similar decision made for aspect_ratio, even though the Swift version can accept a single float.

liveview-client-swiftui/lib/live_view_native_swift_ui/modifiers/aspect_ratio.ex

Lines 1 to 8 in e16e8aa

	defmodule LiveViewNativeSwiftUi.Modifiers.AspectRatio do
	use LiveViewNativePlatform.Modifier
	modifier_schema "aspect_ratio" do
	field :aspect_ratio, {:array, :float}, default: [1.0, 1.0]
	field :content_mode, Ecto.Enum, values: ~w(fill fit)a
	end
	end

But for scale_effect, I don't think it's very clear to a non-Swift programmer that something called size or CGSize is actually a width and height scaling ratio. I've always felt that was an awkward Apple contrivance. For someone not familiar with Swift, width and height as individual params seem more obvious and simpler.

defmodule LiveViewNativeSwiftUi.Modifiers.ScaleEffect do
   use LiveViewNativePlatform.Modifier

   alias LiveViewNativeSwiftUi.Types.UnitPoint

   modifier_schema "scale_effect" do
     field :width, :float, default: 1.0
     field :height, :float, default: 1.0
     field :anchor, UnitPoint
   end
 end

What are your opinions? Do we want to always map as closely as possible to the SwiftUI function signatures or should we take some liberties that we think will make LVN more broadly understandable?

[shadowfacts]

In this case, I think you could call it scale and still have the type be {:array, :float}. To me at least, that reads pretty naturally as [x scale, y scale].

Generally we want to stick fairly close to SwiftUI, but if there are cases where that hinders understandability, I think it's fine to depart.