Bug 59836

This is a aggregate bug for recent changes in classes from using short or int to using enums with codes.

Benefits:
* self-explanatory usage rather than needing to list the valid constants in the javadocs
* easier to distinguish arguments in function signatures (not just a 5 ints)
* clearer error messages, no functions needed to convert code to string
* free range checking (less boiler plate code that does the same)
* type safety

Drawbacks:
* some permgen overhead
* type checking execution overhead

Overall, this seems like a good thing.

In effort to maintain backwards compatibility, the following is suggested:

If there is currently
int getSomething();
void setSomething(int);

Then we should add
enum getSomethingEnum();
void setSomething(Enum);

And deprecate
void setSomething(int);
int getSomething();

It's a bit tricky handling getSomething/getSomethingEnum while maintaining backwards compatibility because at some point the signature will abruptly change. Both getters should be offered for a while with a note encouraging users to use the constants or enums rather than using literal values. This is good coding practice anyway to not hard-code literal values, but is especially important with regard to backwards compatibility here.

At least 2 releases later, but not later than POI 4.0:
Delete void setSomething(int);
Delete int getSomething();
Rename enum getSomethingEnum(); to enum getSomething();

In the end, we will have
enum getSomething();
void setSomething(enum);
as the only two methods.