Dynamically determine nodata index based on multiple heuristics

[jackiryan]

Description

This change is intended to fix an issue with palettizing browse images with a nodata value. Input data in general can have a color palette enter HyBIG in a number of ways:

1. supplied from a remote source, such as the "RelatedUrls" of a UMM-Var metadata entry (example: https://cmr.uat.earthdata.nasa.gov/search/concepts/V1263149414-LARC_CLOUD.html)
2. embedded in the source granule, such as for a granule from this collection: https://search.uat.earthdata.nasa.gov/search/granules/collection-details?p=C1264760805-POCLOUD
3. supplied directly in the "params" dictionary when HyBIG is invoked.
4. Not supplied at all, in which case a greyscale colormap is applied automatically

In each of these cases, the intended behavior of where the nodata value is intended to go in the palettized raster is a little different:

1. When using a remote source, the colormap txt file is read in to a ColorPalette object, which stores the nodata value as self.ndv but does not have a concept of a "nodata index". The location of the "nv" line in the input text colormap is lost when the ColorPalette object is instantiated. Due to this, our default behavior should be to put the "nodata index" at 0 when palettizing these rasters, unless there is a specific color entry that matches the nodata value.
2. Embedded color maps use the same logic as above.
3. Same as above.
4. The default color map puts the nodata index at the end. This is legacy behavior that we want to carry forward.

Jira Issue ID

GITC-8020

Local Test Steps

Ran unit tests. One unit test, test_convert_singleband_to_raster_with_colormap_and_bad_data had its expected result modified to match the behavior when there is "nv" in the input colormap but no explicit "nodata index" - we want to use a nodata index of 0 in that case instead of len(levels) - 1.

PR Acceptance Checklist

• Jira ticket acceptance criteria met.
• CHANGELOG.md updated to include high level summary of PR changes.
• docker/service_version.txt updated if publishing a release.
• Tests added/updated and passing.
• Documentation updated (if needed).

[jtroberts]

The code looks good to me but the 4 failing checks should be investigated.