Add int64in/out record support

[AlexanderWells-diamond]

Add support for the int64in and int64out record types.

There's two TODOs and some test failures that needs discussion:

• The DBR_* types we use come from epicscorelibs, however its latest version does not define the (new) DBR_INT64 and DBR_UINT64 types. Is it worth trying to get a PR through that module that adds these codes before merging this?
• I don't fully understand the note next to DBF_ULONG as to why it is an int32, rather than uint32. Will I need to do the same kind of transformation for DBF_UINT64?
• There are a variety of test failures due to caget not being able to transport an int64, instead transporting it as a float. Should I special-case these tests to accept this, or is there a better mechanism to force what we want? I see that caget does NOT claim to support datatype=DBR_INT64.

Various reference materials:
Changelog for introduction of the records: https://github.com/epics-base/epics-base/blob/7.0/documentation/RELEASE_NOTES.md#ioc-database-support-for-64-bit-integers
EPICS header file that defines both DBR_ and DBF_ codes: https://github.com/epics-base/epics-base/blob/7.0/modules/database/src/ioc/dbStatic/dbFldTypes.h

Closes#160Closes#118

[github-actions]

Unit Test Results

8 files ± 0 8 suites ±0 10m 12s ⏱️ +18s
297 tests + 13 281 ✔️ +13 16 💤 ± 0 0 ❌ ±0 
2 376 runs +104 1 928 ✔️ +72 448 💤 +32 0 ❌ ±0 

Results for commit d38df9b. ± Comparison against base commit 4bbc933.

This pull request removes 14 and adds 27 tests. Note that renamed tests count towards both.

tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[WaveformIn-expected_value12-ndarray]
tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[WaveformOut-expected_value11-ndarray]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformIn-bytes-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformIn-float-[12.345]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformIn-int-[567.]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformOut-bytes-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformOut-float-[12.345]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformOut-int-[567.]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_set[WaveformIn-bytes-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_set[WaveformIn-float-[12.345]]
…

tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[WaveformIn-expected_value14-ndarray]
tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[WaveformOut-expected_value13-ndarray]
tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[int64In-0-int]
tests.test_record_values.TestDefaultValue ‑ test_value_default_pre_init[int64Out-0-int]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformIn-list-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[WaveformOut-list-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[int64In-int-65]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_initial_value[int64Out-int-65]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_set[WaveformIn-list-[72 69 76 76 79 0 87 79 82 76 68]]
tests.test_record_values.TestGetValue ‑ test_value_pre_init_set[WaveformOut-list-[72 69 76 76 79 0 87 79 82 76 68]]
…

♻️ This comment has been updated with latest results.

[coretl]

There are a variety of test failures due to caget not being able to transport an int64, instead transporting it as a float. Should I special-case these tests to accept this, or is there a better mechanism to force what we want? I see that caget does NOT claim to support datatype=DBR_INT64.

pvget should support it though, so you can use p4p to do those particular tests

[Araneidae]

Looks good to me.

Are we going to have to add these field types to cothread and aioca?

[AlexanderWells-diamond]

Requested changes have been made. Tests are failing due to #158 still waiting for upstream dependencies for Python 3.12.

[Araneidae]

This is fine.