* Add Frontend components for Value Lists Management Modal

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

* Update value list components to use newest Lists API

* 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

* Close modal on outside click

* Add hook for using a cursor with paged API calls.

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.

* Better implementation of useCursor

* 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.

* Fixes useCursor hook functionality

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.

* Add cursor to lists query

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

* Do not validate response of export

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

* Fix double callback post-import

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

* Update ValueListsForm to manually abort import request

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.

* Default modal table to five rows

* Update translation keys following plugin rename

* Try to fit table contents on a single row

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.

* Add helper function to prevent tests from logging errors

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.

* Add jest tests for our form, table, and modal components

* Fix translation conflict

* Add more waitForUpdates to new overview page tests

Each of these logs a console.error without them.

* Fix bad merge resolution

That resulted in duplicate exports.

* Make cursor an optional parameter to findLists

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

* Tweaking Table column sizes

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

* Fix bug where onSuccess is called upon pagination change

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.

* Fix failing test

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

* Hide page size options on ValueLists modal table

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

* Update error callbacks now that we have Errors

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

* Synchronize delete with the subsequent fetch

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.

* Cast our unknown error to an Error

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.

* Import lists code from our new, standardized modules

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>