Per phase calculated intensities

[rowlesmr]

Initial go at adding per phase calculated intensities.

I put in PD_CALC_COMPONENT as a child of PD_DATA, so they can be looped with all the other data.

[jamesrhester]

So some comments on this:

1. PD_CALC_COMPONENT is not a child category of PD_DATA as that would imply the components could be listed together with measurements and processed intensity. The whole point of the PD_CALC_COMPONENT category (i.e. loop) is that the contributions of each phase are listed separately, not together. To make sure the 2 theta points match, it is enough to make _pd_data.point_id the _name.linked_item_id of _pd_calc_component.point_id
2. the presentation order should not be in the PD_CALC_COMPONENT category as the presentation order is not looped (ie listed with every point). Some other category containing overall information would be the best place for this, maybe even pdblock. The PD dictionary is a bit confusing with data names, as for historical reasons sometimes the data name is not in the form `.

[rowlesmr]

No worries. There's a lot of interdependence on the looping here which tripped me up.

1. I'm going to assume we don't want our own calc_component versions of 2theta, d_spacing, time_of_flight..., and so we need to list the point id in the calc_component loop and the proc/meas/calc loop to allow a mapping between them
2. I think the original ideas in #3 had _pd_phase.presentation_order, but PD_PHASE is a Loop category. Maybe PD_CALC_OVERALL is a good place to put it as _pd_calc.component_presentation_order. Yes, it doesn't follow the _<category>.<object> convention, but it uses an existing category in the way it is already being used.
3. Yes. I'll make a _pd_calc.component_intensity_net_list and _pd_calc.component_intensity_total_list in PD_CALC to allow looping there.

[jamesrhester]

1. So I think the pd_calc_component category with data names is ready to be merged now - we can sort out dREL later.
2. I don't understand why the name for _pd_calc.component_presentation_order is not written _pd_calc_overall.component_presentation_order? What is the reason to deviate from _<category>.<object> here?
3. The definition for _pd_calc.component_intensity_net_list et. al. should explain that the order of presentation of categories is given in _pd_calc(_overall).component_presentation_order. This information will also be available in dREL form but programmers are likely to prefer the human-readable form.

[rowlesmr]

2. I don't understand why the name for _pd_calc.component_presentation_order is not written _pd_calc_overall.component_presentation_order? What is the reason to deviate from _<category>.<object> here?

The other dataname in PD_CALC_OVERALL only had pd_calc.. Then again, there is only one other. It's now _pd_calc_overall.component_presentation_order

3. The definition for _pd_calc.component_intensity_net_list et. al. should explain that the order of presentation of categories is given in _pd_calc(_overall).component_presentation_order. This information will also be available in dREL form but programmers are likely to prefer the human-readable form.

Added.

[jamesrhester]

Looking good. All that could still be added as far as I can tell is _pd_calc_component.phase_id and _pd_calc_component.diffractogram_id data names to indicate in a machine-readable way that the information in pd_calc_component is per phase, per diffractogram. However, as there are other categories that also need one or both of these added, I think it is best to leave these additions as a separate pull request.