chore: add version ceilings to scientific Python dependencies

[lukepayyapilli]

Summary

@tompollard Implements the proposal (closes #208) to add version ceilings to the scientific Python stack.

Changes

- "numpy >= 1.19.1",
+ "numpy >= 1.19.1, <3",
- "pandas >= 2.0.3",
+ "pandas >= 2.0.3, <4",
- "scipy >= 1.10.1",
+ "scipy >= 1.10.1, <2",
- "statsmodels >= 0.14.1",
+ "statsmodels >= 0.14.1, <1",

Rationale

Per semantic versioning, major version bumps can include breaking changes. The pandas 3.0 release (#207) demonstrated this with strict string dtype enforcement.

Dependency	Ceiling	Reasoning
pandas	<4	Just broke with 3.0 (string dtype enforcement).
numpy	<3	numpy 2.0 had significant breaking changes.
scipy	<2	Scientific APIs can change between major versions.
statsmodels	<1	Statistical APIs can change; currently pre-1.0.
Jinja2	none	Simple templating use, stable API.
openpyxl	none	Stable Excel API.
tabulate	none	Simple formatting, stable API.

Benefits

• Protects users from unexpected breakage when dependencies release new major versions.
• Gives maintainers time to test and adapt to breaking changes.
• Makes the supported version contract explicit rather than implicit.

Related

• Issue Add version ceilings to dependencies to protect against future breaking changes #208 (proposal)
• PR fix: pandas 3.0 compatibility for strict string dtype enforcement #209 (pandas 3.0 compatibility fix)

[tompollard]

Thanks, I'll merge this now with the assumption that the Pandas ceiling of <4 will be correct shortly (hopefully the V3 issues will all be addressed in #209).