UrlParams: Intent system update, split into configuration and propreties

[toger5]

Needed for implementing #3372 more cleanly

This PR updates the intend system. We want to solve this before starting on the telephone usecase implementation to prohibit us needing to make too many rust-sdk PR's and to converge to a solution we think brings the best benefits to maintain the url paramters.

This solution tries to get us the most features from this list:

• Authority in EC (change all platforms at once)
• Flexible usage of EC in other clients (secondary)
• Very simple/fast setup on EX (one prop preferably)
• As much transparency as possible (intent -> changes things the dev did not know about anymore) No time should be wasted on: “was this handled by an intent, do i need to look into the intent description, or do i need to look through feature list”
• No artificial entanglement (flexibility) If the intent “telephoneOneOnOne” controls “autoleave” (for example) we will always get “startUnmuted” if we want autoleave. Sometimes only one of them is desired.
• (off topic but related) We want EC to feel like a custom react component with properties. It can execute functions (send call member event, encryption keys) but things like “sendNotifyEvent” might be configurable as params

By implementing intends with a "preset" architecture:

• The intend is optional and it is possible to tweak each individual configuration
• Each intend is a list of presets that also adapt based on platform
• Web + EX configurations should only set the intend and keep all the other options blank. So everything can get controlled in the EC codebase.
• It is still possible to provide an intend but overwrite a subset of the configuration properties via individual query parametrs.

This PR changes:

• remove all deprecated fields
• split the url parameters into UrlProperties and UrlConfiguration (configuration are the ones where you can skip with one intend, properties are always required)

[robintown]

This should be "notification", because it's possible to start a call under this intent too if the previous call ends while you're on the lobby screen.

[toger5]

And the logic for checking this would run in EC right?

[toger5]

sendNotificationType is slightly wrong. More correct would be requestSendingNotificationtype

(I remember we discussed that we do not have a "should do sth if checks pass" var prefix)

[robintown]

Non-blocking: Since the difference between these cases is pretty minute (only skipLobby changes), it'd be nice to collapse these two branches into one, so it's clearer what changes