Fix half-light ratio value

[rmjarvis]

I just chatted with Patricia Larsen about the half-light radius convention that has been confusing for a while now. We ended up digging into the provenance of the hlr quantities all the way back up the chain.
It turns out that the quantities called size_*_true are actually the values we want for half-light-radius, and not the major axis, as it says in the GCR schema. So the line in skycatalogs where we compute hlr = sqrt(a*b) is not correct.

            a = self.get_native_attribute(
                f'size_{my_component}_true')
            b = self.get_native_attribute(
                f'size_minor_{my_component}_true')
            assert a >= b
            hlr = (a*b)**0.5   # approximation for half-light radius

should become simply

            hlr = self.get_native_attribute(
                f'size_{my_component}_true')

It also means that DC2 sizes were correct, and not too large by a factor of sqrt((1+e)/(1-e)) as we thought.

[JoanneBogart]

After further discussion with Patricia it seems what we want are the cosmodc2 native quantities
morphology/diskHalfLightRadius and morphology/spheroidHalfLightRadius. These are currently not mapped to any other names by GCRCatalogs (though the plan is that they will be) and are not available from existing skyCatalogs. I propose that new skyCatalogs when created should fetch and store these quantities, using the native cosmoDC2 (later diffsky) names, though column names could be changed for the skyCatalogs files. Within skyCatalogs my preference is to not use the names size_bulge_true, size_disk_true since these names have had different meanings in the past.

[JoanneBogart]

Could this fix wait for diffsky?

[JoanneBogart]

Looking at this yet again, size_true and size_minor_true are handled entirely differently from the quantities skyCatalogs has been using (size_<cmp>_true, size_minor_<cmp>_true) and the latter are not derived from the former. For example size_disk_true is just another name for morphology/diskMajorAxisArcsec
I don't think this changes what should be done in the future: use the native quantities Patricia suggested. But it probably means the existing calculation is not wrong in the way suggested above.