Forms: Untangle the blocks from the shortcodes

This is a summary of a previous discussion: p1739433998885779-slack-C086RGTJT1D

## Problem

Currently the Jetpack plugin provides a set of form blocks and shortcodes. These arcitecture of the blocks and shortcodes are intertwined. Forms in jetpack were originally implemented as shortcodes. When the project came to implementing form blocks, the decision was to leverage the existing shortcode feature set, and so the blocks output shortcodes on the frontend of a user's site, which are then processed from shortcodes to html.

This architecture leads to some difficulties:
- Developing anything new for forms is more complicated and takes longer. Both blocks and shortcodes should be tested. More complexity/scope means more blind spots and opportunity for bugs.
- New block features must also work for shortcodes, so this constraint limits possibilities.
- Some block functionality requires that blocks output HTML and not shortcode syntax. For example, particular block styles expect to be able to add classnames to block html (using the HTML Tag Processor)

## Proposal

The proposal is to incrementally stop development on the shortcodes in favour of only developing the blocks. The shortcodes enter a sort of maintenance mode, where they can still be used, and might receive bug fixes, but perhaps users are encouraged to switch to blocks. The dependency the blocks have on shortcodes is severed and future development largely occurs on the blocks, especially when it comes to feature development.

## How

I think it's worth trying to migrate one block at a time away from using shortcodes, hopefully starting with form fields, but there may be a need to wrangle some aspects of the form itself. The first block attempted can serve as a feasibility test. If it's not possible to take this approach, it'll be something that we quickly find out!

By doing it this way, hopefully it won't impact writing new features or fixing bugs for forms as much as undertaking a big re-write in one go.

Something else that I think will be worth tackling at the same time - currently all the form field blocks share a lot of code and are all registered in the same files. I think it'd be a good idea to implement each one more idiomatically in its self-contained folder, each with it's own block.json, registration and rendering code. This might require unDRYing some parts (introducing some duplication), but I think that's ok.

This can hopefully help as a signal for other devs - if a form block is in its own folder, it's been migrated and doesn't depend on shortcodes any longer.

No files or tests are named. Start by mapping the form field block registration and rendering code, the shared files mentioned in the proposal, and the shortcode paths they depend on. Define the feasibility of migrating one form field block, including its own block.json, registration, and rendering code, without the shortcode dependency.

Written by the indexing model from the issue text.