Enable Multiple Custom "Edit Form" Screens with Submit/Cancel Logic

**Summary**
Users need the ability to create multiple, distinct "Edit Form" screens for a single row of data, similar to how "Open Form" works for adding new items. Currently, developers are forced to use a single "Edit Screen" per table, heavily relying on complex visibility conditions, or use "Show New Screen" which lacks transactional safety (Submit/Cancel) because it updates data in real-time.

**Current Problem**
* **The "One Edit Screen" Limit:** There is only one default "Edit Screen" configuration per data row. If an app requires different editing interfaces for different user roles or process stages, developers must cram all fields into one screen and manage dozens of visibility conditions.
* **"Show New Screen" Risk:** While the "Show New Screen" action allows for custom layouts, the components inside are "live" (bound directly to the column). There is no buffer. If a user types a mistake or changes their mind, the data is already overwritten. There is no built-in "Cancel" or "Save" workflow to confirm changes.

**Examples/Scenarios**
* **Role-Based Editing:** An "Admin" needs to edit financial fields of a Project, while a "Manager" should only edit the description. Currently, both must share the same Edit Screen with complex logic to hide/show fields.
* **Workflow Stages:** A CRM lead needs different fields to be editable when in "New" status vs. "Closed" status.
* **Data Integrity:** A user wants to edit a complex record but realizes they made a mistake. In a standard Form, they click "Cancel" and nothing changes. In a Custom Screen (the current workaround), the data is destroyed instantly as they type.

**Why This Matters**
* **Simplifies Development:** Drastically reduces the need for "Visibility Condition" spaghetti logic.
* **Data Safety:** Prevents accidental data corruption by restoring the "Submit/Cancel" transaction model to custom edit views.
* **Better UX:** Allows for tailored editing experiences that fit the specific context of the user, rather than a generic "one size fits all" edit screen.

**Suggested UX**
* Add a new Action: **"Show Edit Form"** (distinct from "Edit" or "Show Form").
* This screen should behave like an "Add Form" but populate fields with the current row's data.
* **Buffered Edits:** Changes made in this screen should not write to the table until the user hits "Submit/Save".
* **Multiple Views:** Allow developers to create multiple different "Edit Form" layouts for the same table and trigger them via actions.