Migrate from attr to attrs

[tovrstra]

This is another part of the renovation items in issue #313.

We used the attr library, which has been redesigned into the attrs library with an improved API. The main improvements in attrs are clearer names and more convenient default arguments. This is most notable in the changes of:

@attr.s(auto_attribs=True, slots=True, on_setattr=[attr.setters.validate, attr.setters.convert])

into

@attrs.define

This update also comes with two strongly related cleanups:

• Type hinting of NumPy arrays should be done with numpy.typing.NDArray instead of numpy.ndarray. This is a technical detail but useful because class attributes (defined with attrs) often have type hinting.
• Implicit optional attributes of the IOData object are turned into explicit optional ones, to be more in line with PEP 484. The required changes were at the same lines that were affected by the attrs update.

I'm not sure yet if the tests will keep working on Python 3.9 because type hinting has evolved strongly over the last five Python releases. If all works, we may replace a few older type hints by more modern forms:

• Otional[X] -> x | None
• Union[A, B] -> A | B

[tovrstra]

For Python 3.9, the older style of type hinting is required, Optional[X] instead of X | None, which is now fixed.

I will YOLO-merge this on Wednesday, June 5, unless approved earlier.

[sonarqubecloud]

Quality Gate failed

Failed conditions
11.3% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud

[deepsource-io]

Here's the code health analysis summary for commits a9e209d..6047506. View details on DeepSource ↗.

Analysis Summary

Analyzer	Status	Summary	Link
Shell	✅ Success		View Check ↗
Python	✅ Success		View Check ↗

---

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

[PaulWAyers]

I'm supportive of the change, but recognize that, once again, we are in danger of diverging between QC-Devs packages, which makes things annoying. I'm OK to use iodata as a trial balloon for these changes, but we need a timeframe to roll (selected or all) changes out across repositories too.

[tovrstra]

I understand, I'm working my way through a lot of changes these days.

I didn't mention this before, but it may be reassuring: most of these changes are based on what is or was outdated in IOData, and what I see in other (popular) Python or other repositories, the tools they use etc. I'm hoping to move to somewhat more long-lived CI solutions. Of course, you never know for sure, but if something is popular or widely endorsed, it seems worth a try.