This issue is a follow up to #1006

Currently, when you submit an ATT&CK configuration in the web UI, the flow is:

1. ATT&CK configuration is submitted to the back-end.
2. The back-end converts the ATT&CK configuration into a regular configuration and applies the new configuration.
3. The front-end pulls the new, regular configuration from the back-end.

The ATT&CK configuration does not contain enough information for the front-end to simply determine whether or not it is safe. Therefore, the front-end relies on the back-end to translate the ATT&CK config into a regular config before it can evaluate safety. The front-end can then only warn the user, not prevent submission as in #1000.

Ideally, the modal dialog shown when unsafe ATT&CK configurations are submitted would be identical to when regular configurations were submitted. To resolve this

1. Create a new endpoint on the back-end that translates an ATT&CK config into a regular configuration. Return the regular configuration to the caller
2. Modify the front-end to call the new endpoint
3. In the front-end, verify that the config returned from the new endpoint is safe. Show the appropriate modal dialog.
4. If the config is safe or the user has acknowledged the risk, submit the new config to the backend.