ENH: Add support for reading value labels from 108-format and prior Stata dta files
- [x] closes #58154
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

This change extends support for reading value labels to Stata 108-format (Stata 6) and earlier dta files.
cc @bashtage One of the type checks fails because in various places the value table codes are expected to be floats (dict[float, str]) whereas in fact they are stored as ints (dict[int, str]). I think there are two options to make this work:

1. Cast the codes to float when read and update the newly added type hints to match elsewhere, but this would break anything that relies on the existing behaviour
2. Change the existing type hints to expect int keys, but this might not match the intent of the original author As for typechecking, you can probably need to replace `self._value_label_dict[labname][val[i]]`  with `self._value_label_dict[labname][int(val[i])]` since it will be hard to convince the type checker that `val` is a 1-d array of int which would be needed to let it know that `val[i]` was an int.
 > As for typechecking, you can probably need to replace `self._value_label_dict[labname][val[i]]` with `self._value_label_dict[labname][int(val[i])]` since it will be hard to convince the type checker that `val` is a 1-d array of int which would be needed to let it know that `val[i]` was an int.

It seems to be complaining about a mismatch with lines like `def value_labels(self) -> dict[str, dict[float, str]]:` elsewhere in the file. I think I could make it happy by changing the type hints I added to match this, but then this wouldn't match the actual content of the data. > Some comments on what it here. Overall I think the cyclomatic complexity has gotten too high and I think it would be better to pull these up as two private methods, one for reading 108+ and the other for older formats. Would let you avoid a long `if...else...` clause.

I did wonder about splitting it into functions, but didn't want to change too many lines. I am happy to have a go at implementing this. Thanks @cmjcharlton 