Optionally refactor handling of array_length int subclasses in StaticArrayTypeSpec

[michaeldiamant]

Optionally proposes a refactoring to the question raised in #322 (comment).

Rationale: It's less error prone to centralize the subclass check in StaticArrayTypeSpec rather than have the downstream user remember to cast.

Assumption: It's safe to treat any int subclass as int. The intuition feels reasonable though it should be double checked.

[tzaffi]

niceeee!

[tzaffi]

Optionally proposes a refactoring to the question raised in #322 (comment).

Rationale: It's less error prone to centralize the subclass check in StaticArrayTypeSpec rather than have the downstream user remember to cast.

Assumption: It's safe to treat any int subclass as int. The intuition feels reasonable though it should be double checked.

Subclassing int is an unlikely situation. We should discourage it in this repo except for a really compelling reason.

Ok, I see now that the IntEnum introduced for Address in #289 is a subclass of int