Fixing issue in CDB considering the channel id an int

[pscheidler]

The main issue is that the ChannelID element in the CDB is considered an Int, and most other places it is considered a UInt.

Small question: SubChannelsIDs are considered Ints, which is consistent, but odd. Should IDs generally just be uints?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.32%. Comparing base (f406a63) to head (c55276a).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #158   +/-   ##
========================================
  Coverage    75.32%   75.32%           
========================================
  Files           13       13           
  Lines         4016     4016           
========================================
  Hits          3025     3025           
  Misses         991      991           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[StokesMIDE]

Small question: SubChannelsIDs are considered Ints, which is consistent, but odd. Should IDs generally just be uints?

All IDs (channels, subchannels, calibration, etc.) should probably be uints.
Similarly (but a different issue), many of the StringElements should be UnicodeElements. I think most were made StringElements (which are limited to printable 7-bit ASCII) as an oversight.

[StokesMIDE]

We should change all the ID/IDRef elements to UInteger. Since we don't use any higher than the low 100s, this shouldn't cause any problem with existing data. We might as well do it in one PR.

[pscheidler]

Small question: SubChannelsIDs are considered Ints, which is consistent, but odd. Should IDs generally just be uints?

All IDs (channels, subchannels, calibration, etc.) should probably be uints. Similarly (but a different issue), many of the StringElements should be UnicodeElements. I think most were made StringElements (which are limited to printable 7-bit ASCII) as an oversight.

I'll leave this one for a following PR

[StokesMIDE]

Was this changed the other way (UIntegerElement -> IntegerElement) on purpose? Do we ever want negative channel ID references here?

[pscheidler]

Good catch! I'd changed it earlier when I thought the intent was for SubChannels to be ints

Suggested change

	<IntegerElement name="BivariateSubChannelIDRef" id="0x4B07" multiple="0" minver="1">SubChannel ID of the subchannel to be used as the 2nd parameter for bivariate compensation</IntegerElement>
	<UIntegerElement name="BivariateSubChannelIDRef" id="0x4B07" multiple="0" minver="1">SubChannel ID of the subchannel to be used as the 2nd parameter for bivariate compensation</UIntegerElement>