[MOO-2069] : Signature widget update for 11-12

[saurabhchavan1711]

Checklist

• Contains unit tests ✅
• Contains breaking changes ✅
• Compatible with: MX 11
• Did you update version and changelog? ✅
• PR title properly formatted ([XX-000]: description)? ✅
• Works in Android ✅
• Works in iOS ✅
• Works in Tablet ✅

Feature specific

• Comply with designs ✅
• Comply with PM's requirements ✅

This PR contains

• Bug fix
• Feature
• Refactor
• Documentation
• Other (describe)

What is the purpose of this PR?

The PR introduces a new option in the signature widget of saving signature directly as a image . In the existing flow , signature's base64 string needs to be store in attribute of entity . Then end user has to create a nanoflow , use base64decodetoimage jsaction to convert this base64 to blob and then upload signature which is a overhead and is error prone . With this new option everything is taken care under the hood and user don't really need to store value to attribute then user base64decodetoimage jsaction. With this change the signature widget feels more a like end to end .

Added migration document and its related images as per suggestion of Docs team

What should be covered while testing?

• Test the migration of basic 10.24 signature mendix project to the latest studio pro and see if the migration doc is helping it out for resolving the errors while migrating.
• Test the new freshly created project with this new signature functionality.
• Test calling a nanoflow , microflow and save changes action for on sign end property and see if signature is getting stored correctly
• Test for both online and All Objects synchronization mode of entity
• Test different negative scenarios of assigning static images to Image property , Calling action other than call a nanoflow , microflow or save changes for on sign end property
• Check if newly updated description is suitable and guides the user for Image property and on sign end action in Events tab

[YogendraShelke]

Please check my comments on #499

[MxKevinBeqo]

Unless absolutely required by some external factor or rule:

I would suggest we keep the same display name for this attribute because for the customer the purpose of the attribute does not change i.e. "what to trigger when clicking the Save button".

The renamed attribute also might bring confusion, because it sounds like "what happens when you end/finish the signing drawing".

[MxKevinBeqo]

Since this is a breaking change, I would prefix this note with a [BREAKING] or something similar, and add a mention for the corresponding README section for quick-reference to the nice migration you prepared 🙌 .