Allow arrays of strings to be used with Waveforms

[AlexanderWells-diamond]

Allow creation records like:

t1 = builder.WaveformOut(
    "TEST1",  initial_value=["ZERO", "ONE", "MANY"]
)
t2 = builder.WaveformOut(
    "TEST2",  initial_value=[b"ZERO", b"ONE", b"MANY"]
)

Where each element of the array is treated as an EPICS string

Values returned will always be Python string lists:

> t1.get()
["ZERO", "ONE", "MANY"]
> t2.get()
["ZERO", "ONE", "MANY"]

(valid) Unicode characters may also be passed in, and will be returned as-is. Note that it is not always obvious how many Unicode characters can be safely entered into EPICS's 40 character string limits.

[codecov[bot]]

Codecov Report

Merging #102 (65f8bd8) into master (565bca1) will increase coverage by 0.19%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #102      +/-   ##
==========================================
+ Coverage   87.15%   87.34%   +0.19%     
==========================================
  Files          14       14              
  Lines         981      996      +15     
==========================================
+ Hits          855      870      +15     
  Misses        126      126              

Impacted Files	Coverage Δ
softioc/builder.py	97.64% <100.00%> (+0.02%)	:arrow_up:
softioc/device.py	95.81% <100.00%> (+0.21%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[github-actions[bot]]

Unit Test Results

     15 files  ±    0       15 suites  ±0   27m 47s :stopwatch: -21s    271 tests +  22     255 :heavy_check_mark: +  12    16 :zzz: +  10  0 :x: ±0  4 065 runs  +330  3 475 :heavy_check_mark: +180  590 :zzz: +150  0 :x: ±0 

Results for commit 65f8bd88. ± Comparison against base commit 565bca1f.

:recycle: This comment has been updated with latest results.

[AlexanderWells-diamond]

The current state of the branch is that you can create a WaveformIn/Out with an initial_value of an array of (byte) strings, but you cannot set that value at a later time. This is because if there is no dtype, numpy defaults to float64, and trying to coerce an array of byte strings to float64 is simply nonsense.

If you specify an FTVL or dtype of the relevant type during record creation, the record does behave as expected.

I'm unsure if we can support arrays of strings quite as freely as we could in version 3.2.1 - I don't see a neat way around the implicit numpy conversion.