Add form event hooks

[signebedi]

This should be special behavior on certain event triggers, like:

1. on_create
2. on_delete
3. on_update
4. on_duplicate
5. on_read[_one]
6. on_sign

Special event hooks like onApproval / onDisapproval will make more sense to implement using the approval process, see #62 and #39.

[signebedi]

We should also support a handful of built-in behaviors, like sendMail ( subj, content, to_addr ) or setAttr ( form_name, form_id, field, value ).

[signebedi]

Implement send_mail built in event hook behavior
This will look something like:

send_mail:
  template: form_created
  method: static
  target: [email protected]

Where the template points to one of the template names in the email config, method is an enum of ['static', 'group', and 'relationship'], and target is the value used to select the emails to send, based on the method. So, the example above will always send Bob a form_created email to [email protected] when a form is submitted. But, if we wanted to send this to all members of the default group, we could do the following:

send_mail:
  template: form_created
  method: group
  target: default

[signebedi]

Implement set_value built in event hook behavior
This will look something like:

set_value:
  selector_method: from_field
  value_method: static
  target_form_name: leave_requests
  target_field_name:  approval_status
  target_document_id: request_id
  value: "approved"

This logic is a little more complex, because we need to choose methods for two things: first, how to select the submission to assign the value to; second, how to select the value to assign to that submission. For this, we create selector_method and value_method, respectively. These are enums of ['static', 'from_field']. If selector_method is assigned "static", then target_document_id should be a assigned an actual document ID like 664eab5c46c99199a7b22ab7. If it is assigned "from_field", then target_document_id should be assigned a field that exists in the form that has just triggered the event handler - which should contain a document_id value.

Likewise, if value_method is set to "static", then value is expected to be a static value; but, if value_method is set to "from_form", then value should correspond to a form field in the form that has just triggered the event handler, see example below.

set_value:
  selector_method: from_field
  value_method: from_field
  target_form_name: leave_requests
  target_field_name:  approver
  target_document_id: request_id
  value: __metadata__created_by

target_form_name and target_field_name should be static values.

[signebedi]

Add a __config__ param to forms to contain form-level params
This allows us to set form-level parameters, like a form_label, summary_fields, and/or enable_title_field. (#286) It also enables us to configure event triggers. We can also add a presubmit_message popup this way, add a require_password, and allow_csv_uploads.

[signebedi]

RelationshipType reciprocal_name should be nullable but unique if set
When we are trying to aggregate people by relationships, that means we often need to be able to query on reciprocal_name ... as such, it should be unique.

[signebedi]

Implement create_submission built in event hook behavior
This will look something like:

create_submission:
  form_name: example_form
  values:
    field_name_1:
      method: static
      value: "This text will always be the same"
    field_name_2:
      method: from_field
      value: some_field_name
    field_name_3:
      method: from_field
      value: __metadata__some_metadata_field

This will create an example_form form submission with the values set in the values dict. Should we support setting metadata fields too, just using the __metadata__ field name prefix in the values dict keys?

[signebedi]

Implement http_request built in event hook behavior
This will look something like:

- type: http_request
  target: https://api.jira.com/api/v1/create/
  method: post
  headers:
    X-API-KEY:
      value_method: static
      value: laksjdfhkjasdhfwj2317-sas-d
  body:
    request_type:
      value_method: from_form
      value: request_type
    description:
      value_method: jinja2
      value: "This is the description of a {{request_type}} submitted by {{__metadata__created_by}}"

This will submit an http request to the designated target and include the relevant headers and body passed by the system. You also need to specify the HTTP method (get, post, patch, put, delete) for the request. There are three ways to pass data: static, from_form, and jinja2. Jinja2 will allow you to embed values from within the form itself into a jinja2 string.