onlyIfModified decorator - deploy only if specified resource properties are different than currently deployed resource properties

**Is your feature request related to a problem? Please describe.**
The recently introduced `onlyIfNotExists` is very nice, but IMHO only useful for resource that one is 100% sure would never change. There are arguably some such resource, like `Microsoft.ServiceNetworking/trafficControllers` (which simply has no properties), but even that is not guaranteed in future ARM API versions (e.g. some property could be added).

Honestly I'm not sure I would ever use this decorator, because I find it too risky - I change some property, deploy and everything seemingly works, except the property was never updated... Sure, there would be a `onlyIfModified` decoration above the resource, but this could very easily be missed - there might be a lot of properties so it's like 100 lines above, or it's modified by people who aren't bicep experts, or people don't understand this is the behavior (AFAIK it's not even currently documents)...

**Describe the solution you'd like**
Something like `onlyIfModified` would be far more useful in my view - if I changed my resource, everything is deployed normally, and I can be sure my change is applied. And if I didn't, the operation is treated as a no-op and time is wasted (or worse, needless failure is encountered). The abovementioned resource is a great example for that as well - at the time of writing, `Microsoft.ServiceNetworking/trafficControllers` will do a rolling upgrade even if nothing has changed, which actually takes longer than the initial deployment! (not to mention it could possibly fail)

I realize the implementation won't be trivial, because some properties are readonly / auto-generated at the back end, so even if all possible properties were specified in the bicep, they would not 100% match the deployed resource. But I wonder whether some intelligent "subset" check (which is aware of complex objects and arrays) could do the trick? I would prefer to err on the side of caution, so a solution that will **always** deploy if a property changed, but only most of the time (best-effort) would be a no-op if it didn't, would be good enough in my book.