[BUG] Issues setting Python ImageSpec.channelnames values to byte strings

**Describe the bug**
We are currently testing out moving from 2.2.8.0 to 2.2.19.0 and 2.3.11.0 and are running into an issue where we encounter incorrect behavior under Python 2.7 (but I assume 3.7 as well, if explicitly using bytes) where when we attempt to set the channel names on an ImageSpec object to a list of strings (2.7 str) the resulting set values are all empty strings. This does not happen using native Python 3 strings, or if we explicitly convert the 2.7 values to unicode before setting.

**To Reproduce**
Steps to reproduce the behavior:

Testing was done using a simple RGBA render out of Mantra 19.0.

```
>>> import OpenImageIO as oiio
>>> source_image = oiio.ImageInput.open(...)
>>> source_spec = source_image.spec()
>>> source_spec.channelnames
(‘R’, ’G’, ’B’, ’A’)
>>> names = (‘R’, ’G’, ’B’, ’rgba.A’)
>>> names
(‘R’, ’G’, ’B’, ’rgba.A’)
>>> source_spec.channelnames = names
>>> source_spec.channelnames
(‘’, ’’, ’’, ’’)
```
As we can see it's now set to a bunch of empty strings. This does work as expected in 2.2.8.0.

Converting the name list to unicode values does result in the expected behavior:

```
>>> names = tuple([unicode(name) for name in names])
>>> names
(u’R’, u’G’, u’B’, u’rgba.A’)
>>> source_spec.channelnames = names
>>> source_spec.channelnames
(‘R’, ’G’, ’B’, ’rgba.A’)
```

It would seem that in our use case that uncovered this issue we can just update our code to convert to unicode for 2.7 and be okay (tested in 2.2.8.0 as well as 2.2.19.0 & 2.3.11.0) however it would be ideal to get a proper fix.

**Platform information:**
- OIIO branch/version: 2.2.19.0, 2.3.11.0
- OS: CentOS 7.7
- C++ compiler: gcc 9.4.0

Thanks!

Start by reproducing assignment to ImageSpec.channelnames with Python 2.7 byte-string tuples and compare it with unicode values and native Python 3 strings. The fix is complete when byte-string channel names such as ('R', 'G', 'B', 'rgba.A') remain intact instead of becoming empty strings, while the existing unicode behavior remains correct.

Written by the indexing model from the issue text.