feat: dataset editing + new dataset convergence

Added a commit with a major refactor, consolidating the previous work done on this branch to edit readme and meta for an existing dataset with the new dataset creation flow that was recently merged into master.

Both new dataset creation and existing dataset are now consolidated into the same feature in /src/datasetEditor. There are two top-level components, NewDatasetEditor and ExistingDatasetEditor, both of which render DatasetEditorLayout in different ways for their respective UXs.

Both also share the same state, which includes a Dataset which will be mutated when the user edits components, loading and error booleans, and a File for body updates

export interface DatasetEditorState {
  dataset: Dataset
  loading: boolean
  error: string
  // file is used to store the file reference when POSTing a body via form data
  file?: File
}

There is a lot more to do, but as of dc08ea8 the user can create a new dataset from a CSV, and modify the readme and meta before committing. They can also edit existing datasets via a button in the history list.

Still TODO:

PUNT

[ ] We should only show the commit bar when there are changes. This involves comparing the workingDataset with the original. We can punt on this if it's too difficult, but it would be a nice effect to have the commit bar pop up as soon as the first edit happens. (status quo: in NewDatasetEditor, it appears when the file is added, which might be what we want as it forces the user to have a body. In ExistingDatasetEditor the prop is hard coded to true to it always shows.
[x] Dataset Title Editing Behavior - In NewDatasetEditor, the dataset name is stored in component state and used when making the api call to create the new dataset. However, in ExistingDatasetEditor we aren't currently handling a change to the dataset name. Changing the name via the same method we had enabled in the past would require a trip to the server, and I think this would make the user lose their changes unless we add some code to prevent this. Should the user be able to change the name of a dataset they are editing? I tend to think we should disable the name edit field, and make a name change be a bigger deal with its own modal or something. We need the name editor for new datasets for obvious reasons, but I think it's less necessary when editing an existing dataset.
[x] Error handling for the commit api call in ExistingDatasetEditor. We show a loading spinner in the commit button, but don't handle the error or display it.
[x] User should be able to update the body of an existing dataset by dragging in a new file. I think this won't work with the commit api call we are doing at the end of the ExistingDatasetEditor flow, so we should check with @Arqu to see if it's possible ATM.

PUNT

[ ] We have existing components for MetaEditor and ReadmeEditor, but we build the editors into Meta and Readme. I like the pattern of keeping these separate and just calling a different component for editing. If it's not too much work lets separate them again.

Follow-on issues

Add a structure editor

qri-io / frontend

feat: dataset editing + new dataset convergence #631