Make GenericImportEvent.errors.data always a []

Forcing this to be a list greatly simplifies template rendering of these
errors. We can say if errors.data then make a <ul> of each member of
data. For row-level validation this is not so simple, because each error
type appears to have its own schema, but for small number of cases of
file-level errors, it's easy to force this structure.
Make errors use client-appropriate summary text

In otm-legacy, these errors had their own internal status messages which
were more or less duplicated in user-friendly language in the
templates. Since they're plain text and not computer-friendly anyway, we
might as well just store the client friendly text and render as-is.
Show error summary page for file level errors
Prefer generalized errors over specific cases

The generalized MISSING_FIELD error accepts strings of text that
represent the actual fields that were missing. Adding a MISSING_FIELD
error with ['point_x', 'point_y'] or one for each offers the same level
of detail as MISSING_POINTS without requiring the existence of an extra
type. The same goes for MISSING_SPECIES_FIELD. These error types did not
add any additional detail in their error message anyway.
Validate even when there are no rows

We have an error case for EMPTY_FILE, but it was impossible to reach this
case because if the reader object did not iterate once, the file level
validations were not executed.