Refactor CurveAnalysis tutorial description of ScatterTable

[wshanks]

This change refactors the description of ScatterTable in the CurveAnalysis tutorial to try to provide a more intuitive picture of what series and category are. It tries to the split the discussion into two parts: first a high level description of what the terms are intended to mean and then a walkthrough of the default CurveAnalysis flow pointing out how the terms are used in practice.

The short version is that series and category could be used as arbitrary labels, but in practice category is used to distinguish stages of data processing ("raw", "formatted", "fitted") while series is used to label data associated with a specific function (a model but not necessarily one written out as a fit model for the class). Together series and category (and analysis if considering a CompositeCurveAnalysis subclass) should distinguish a specific y vs x curve.

[wshanks]

I marked this as a draft because I haven't tried getting the sphinx syntax correct yet.

[nkanazawa1989]

Thanks Will. I really like new documentation. It's very easy to understand thanks to good amount of examples. I also checked html artifact and docs look okey. I think we can merge after you undraft the PR.

[nkanazawa1989]

Suggested change

	`series` labels and the category of ``"formatted"``.
	`series` labels and the category of ``"formatted"``.

Only this formatted is formatted as a code. I'm fine with this is intentional :)

[wshanks]

Thanks. I changed this to italics. I am unsure about what formatting is most consistent here. There are table column names, string table values, and generic terms like "series" as a set of data rather than the column for labeling that set of data. I tried to use italics for the column names whether referring to the column names specifically (or to the concept in the context of the column name but not for the concept on its own -- I didn't italicize all use of "series") and similarly use italicized and quoted text when referring to table values like "fitted". I could also see using code as the way to interact with this table would be to write out these names and values as strings in the code.

[wshanks]

Thanks @nkanazawa1989!

By the way, one other thing I noticed while working on this was that some terminology might not be ideal. For instance, the "raw" data is what comes out of the data processor, so from some perspective it is more "processed" than "raw".

Also, I wonder if CurveAnalysis should be refactored a little to be more readable. Maybe the documentation should be enough but someone wanting to subclass it and replace parts might look at the code to under exactly how it works. One small example is that table = self._format_data(self._run_data_processing(experiment_data.data())) might become two lines so it is more clear visually that there are two steps that the curve analysis writer could override.