[FEATURE] Add prop fields inputs to the submit an app form

**Is your feature request related to a problem? Please describe.**
I am adding new apps to the App Store in the scope of the "Project App Store" and I see adding props to the test request could be further streamlined, before the app is about to be submitted, and when the app is being reviewed for approval.

**Describe the solution you'd like**
In a similar way that the current Submit An App form includes input to capturing Custom Fields (which become part of the auth variable when the app is added to the Pipedream Registry), the Submit An App form should include input to capturing Props Fields, which are part of the test request. When the app is submitted, Props Fields become placeholders for the user to enter their own prop values.

The solution should include two input tables, one table for capturing Props Fields, where props are defined, and another table should be added to the Execute Test section, where test values for props are set. Prop test values should ideally be submitted to the app for the team to use on their approval testing, and in the test request, the props values are replaced by placeholders.

**Do you have a workaround?**
Yes, I usually inform about props (test values, placeholder suggestions) within the notes I provide besides submitting the app, so that, when PD teams approve, they can enter prop placeholders manually.

**Comparable features in other tools?**
n/a

**Additional context**

Consider the following, on why this is relevant to improve the process on the Project App Store

1.
You can only use props placeholders when the test request returns HTTP 200 and a context message in the response. Otherwise if the HTTP is not succesful (say 400 for a bad request), the submti form won't allow the app to be sent.

In this case, the test request has 3 props: city, state, zipcode. the values were set to each prop's place holders: {your_city}, {your_state}, {your_zipcode}. The API response with HTTP 200 saying the zipcode was not found, so this app can be submitted with placeholders on its props:


2.

Now, consider a test request such that, if you use place holders on each prop, it returns an error:


In this case, it is needed the actual props values are entered for the app to be submitted:


3.

The consequence, is that sometimes for velocity apps are approved with their props values. Or otherwise, placeholders need to be manually entered. This happend with resent, and other apps:


In the test request from resend app above,, to, from, subject, text should have placeholder text, instead of actual values, for the user to replace when they connect their resend account.

4.

In summary, two additional tables to the submit form are needed.

One similar to table A, in the image, where Props Fields are defined (kind of a copy of the current Custom Fields table).

And another similar to table B, in the image, where Prop Fields are given values in order to execute the test request.

However, I think for props, test values should be sent with the app for approval, so that the team approving the app knows which test values to use in the props (we do the contrary for custom fields,, we don't set test custom fields values, for security) as additional information the the props values within the test request code, which are replaced by placeholders.

5.

Here is an example of an app with properly placeholders on a prop (see bellow). PD teams should be able to see test values for props to test on the back end/approval admin page (not depicted bellow)