Right now this just navigates around and verifies that the form is
correctly repopulated; next step will be to modify/asset some changes.

We already were asserting on the population of the Edit form after
creation; this additionally makes modifications, saves them, and asserts
the resulting values on the Rule Details page.

So that expectation failures are less obfuscated, the decision was
previously made to abstract user navigation into functions, but to leave
expectations directly within the test body.

Rule Details are unfortunately unstructured: they're an array of <dt>s
and <dd>s without any hierarchy. To address this, tests
were previously hardcoding the order of these fields, and assertions
were performed by querying for all <dd>s and then indexing with the
hardcoded number (e.g. ABOUT_FALSE_POSITIVES).

However, in addition to being unstructured, these fields are also
_dynamic_, and will be present/absent depending on the data of the given
rule. Thus, we started needing multiple orderings for the different
combinations of rule fields/rule types.

In the absence of refactoring how we build rule details, I'm introducing
a simple helper function to fetch the relevant <dd> by the corresponding
<dt>s text. This should be more robust to change and more declarative.

 Conflicts:
	x-pack/plugins/security_solution/cypress/screens/create_new_rule.ts
	x-pack/plugins/security_solution/cypress/tasks/create_new_rule.ts

Lots of these variables no longer exist upstream and this new test
needed to be refactored.