Imports and uses the hooks provided by the lists plugin. Tests coming
next.

* uses useEffect on a task's state instead of promise chaining
* handles the fact that API calls can be rejected with strings
* uses exportList function instead of hook

For e.g. findLists, we can send along a cursor to optimize our query. On
the backend, this cursor is used as part of a search_after query.

* Does not require args for setCursor as they're already passed to the
hook
* Finds nearest cursor for the same page size

Eventually this logic will also include sortField as part of the
hash/lookup, but we do not currently use that on the frontend.

We were previously storing the cursor on the _current_ page, when it's
only truly valid for the _next_ page (and beyond).

This was causing a few issues, but now that it's fixed everything works
great.

This allows us to search_after a previous page's search, if available.

This is just a blob, so we have nothing to validate.

After uploading a list, the modal was being shown twice. Declaring the
constituent state dependencies separately fixed the issue.

These hooks no longer care about/expose an abort function. In this one
case where we need that functionality, we can do it ourselves relatively
simply.

Dates were wrapping (and raw), and so were wrapped in a FormattedDate
component. However, since this component didn't wrap, we needed to
shrink/truncate the uploaded_by field as well as allow the fileName to
truncate.

enzymejs/enzyme#2073 seems to be an ongoing
issue, and causes components with useEffect to update after the test is
completed.

waitForUpdates ensures that updates have completed within an act()
before continuing on.

 Conflicts:
	x-pack/plugins/security_solution/public/lists_plugin_deps.ts
	x-pack/plugins/security_solution/public/overview/pages/overview.test.tsx

Each of these logs a console.error without them.

That resulted in duplicate exports.

This param is an optimization and not required for basic functionality.

Makes actions column smaller, leaving more room for everything else.

Because fetchLists changes when pagination does, and handleUploadSuccess
changes with fetchLists, our useEffect in Form was being fired on every
pagination change due to its onSuccess changing.

The solution in this instance is to remove fetchLists from
handleUploadSuccess's dependencies, as we merely want to invoke
fetchLists from it, not change our reference.

 Conflicts:
	x-pack/plugins/security_solution/public/lists_plugin_deps.ts
	x-pack/plugins/security_solution/public/overview/pages/overview.test.tsx

 Conflicts:
	x-pack/plugins/lists/public/lists/api.test.ts
	x-pack/plugins/lists/public/lists/api.ts
	x-pack/plugins/lists/public/shared_exports.ts
	x-pack/plugins/security_solution/public/common/lib/kibana/hooks.ts
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/form.test.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/form.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/index.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/modal.test.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/modal.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/table.test.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/table.tsx
	x-pack/plugins/security_solution/public/detections/components/value_lists_management_modal/translations.ts
	x-pack/plugins/security_solution/public/lists_plugin_deps.ts

It looks like this broke because EuiTable's pagination changed from a
button to an anchor tag.

These have style issues, and anything above 5 rows causes the modal to
scroll, so we're going to disable it for now.

We don't display the nice errors in the case of an ApiError right now,
but this is better than it was.

Our start() no longer resolves in a meaningful way, so we instead need
to perform the refetch in an effect watching the result of our delete.

useAsync generally does not know how what its tasks are going to be
rejected with, hence the unknown.

For these API calls we know that it will be an Error, but I don't
currently have a way to type that generally. For now, we'll cast it
where we use it.