Introduce the builder application beta's application initialization

What is in this MR

When a database is created with init_with_data=true we create two dummy tables for the user to play around with, Customers and Projects.

So far the builder application hasn't had anything like this, and after talking about it with @jrmi a few weeks ago, I thought I'd knock up an idea of what it could look like.

When a designer now creates a new builder application, two elements are always added to the Homepage page we create.

1. A heading element that welcomes them to the application builder.
2. A paragraph element that explains that data can be added by adding a data source, or manually adding data from the General tab.

The fun part comes next: if the Customers table hasn't changed its schema since it was created (i.e. if version=initial_version), we'll use it to create a few more elements. I added this test because it simplifies the experience, if didn't check initial_version then we'd have to ensure that multiple fields haven't been altered too much, which could break the demo experience's data source / workflow action.

Edit: I've now changed this behaviour as the version=initial_version idea wasn't working. We'll now:

1. Ensure the "Customers" table exists in the same workspace as the builder application.
2. Check we have the two fields we care about (Name / Last name) and that they're TextFields.

Assuming those two checks pass, we'll use the table record for creating a data source / workflow action.

• A table element points to an auto-generated list data source connected to the "Customers" table. The fields use a mix of data source and form data providers to help illustrate the different ways data can be used.
• A form_container element with two input_text in it. We attach two submit event actions to it:
  1. A create_row workflow action, where the two input_text pass their form data to the "Customers" table's Name and Last name fields. So when the designer tests the page, they can add first/last name to the inputs and append to the "Customers" table.
  2. A notification workflow action, notifying them that the appended row was successfully written to the table.
• A column element, with three columns, where each column has a paragraph in it. The text in each paragraph explains how content can be formatted on your page.

How to test this MR

1. Ensure your "Customers" table has a Name and Last name field, and they're both of type=text.
2. Create a new builder application.
3. Play around with what I've noted in the What is in this MR heading.
4. Go to the "Customers" table. Modify the Name and/or Last name fields (either by renaming them, or changing their type).
5. Create a new builder application.
6. Note how the examples page has no table, and the form has no workflow action tied to it.

Screenshot

Merge Request Checklist

• changelog.md has been updated if required.
• New/updated Premium/Enterprise features are separated correctly in the premium or enterprise folder
• The latest Chrome and Firefox have been used to test any new frontend features
• Documentation has been updated
• Quality Standards are met
• Performance: tables are still fast with 100k+ rows, 100+ field tables
• The redoc API pages have been updated for any REST API changes
• Our custom API docs are updated for changes to endpoints accessed via api tokens
• The UI/UX has been updated following UI Style Guide