Rename "Dataset" to "Entity List"

[matthew-white]

Make this change in:

• Frontend
  • Text
  • Routes
  • API requests
• Backend
  • API endpoints (should we add aliases so that it isn't a breaking change?)
  • API docs
  • Don't rename database tables
  • Maybe don't rename audit log actions?
  • Don't rename "dataset" where it is used only internally in the code (e.g., the frame name)
• User docs

[matthew-white]

Why we decided not to change API endpoints

@lognaturel wrote on Slack:

But for the APIs, maybe we should also consider the option of keeping dataset? It’s confusing but seems like the kind of thing an API consumer could handle.

…

We’ve decided to keep “dataset” for the spec, API, and everything dev-facing in Central. The hope is that this split will be more consistent and less confusing than a partial conversion.

I wrote:

Along the lines of what Sadiq said, the difficulty is that it’s not just mapping /v1/projects/:id/datasets to /v1/projects/:id/entity-lists. When you link a form attachment to a dataset, you do so by specifying "dataset": true in the request body. For a couple of responses (project extended metadata, form attachments), dataset is also in the response body.

[ktuite]

I'm thinking we should update the Problems that mention Datasets. Some of them wind up passed through to frontend like here in the dataset property validation step.

[lognaturel]

Continuing musings from #482 (comment). We need to decide what problem messages should be consistent with: everything else in backend or the universe outside of backend. These messages are at the edge so it's not an obvious decision. My current leaning is to keep everything in backend using 'dataset', even moving forward, and to be sure that problems that have messages with 'dataset' are explicitly handled in frontend and given localizable strings.

[matthew-white]

I'm thinking we should update the Problems that mention Datasets.

This question was separated into its own issue, #487.