remove redundant method calls in DatatypeConverterImpl

[winfriedgerlach]

• both new BigInteger() and Long.parseLong() accept strings with + prefix, there is no need to remove anything (maybe the confusion came from an error in the JavaDoc, I noticed that in Java 11 the JavaDoc for BigInteger(String) doesn't mention the + sign while the JavaDoc for BigInteger(String, int) is correct; the JavaDoc was fixed in later Java versions)
• the extra checks for . or non-digits also make no sense, because they will lead to a NumberFormatException anyway
• there should be a slight performance benefit as well, but microbenchmarking showed that this is insignificant --> correct semantics are more important here

[laurentschoelens]

Same remark as eclipse-ee4j/jaxb-ri#1874

I'd be happy to see every use case handled in the removed function in order to check if nothing is broken.

Also please update copyrights header regarding Oracle or Eclipse situation you're in

[winfriedgerlach]

@laurentschoelens phew, if I would have known about this rabbit hole beforehand, I wouldn't have touched anything...
Turns out that both the old code as well as the new code is incorrect. The old code performs correct validation, but only if the integer starts with + and only for the first digit after the +... The rest of the number is parsed using java.lang.Character#isDigit(int), which accepts 360 other kinds of digits from Unicode 🙈

See https://github.com/jakartaee/jaxb-api/pull/328/files#diff-66f7e84e30bf1ef955f70317f20c9aae7fd656516af68e7c0d816f24df97d80b

I see 3 ways to go from here:

1. leave implementation as it is, people are used to it and nobody seems to have an urgent problem with it
2. apply my suggested code change, which doesn't really make things worse (only for the edgy edge case that only the first digit after a leading + sign matters...) but code a bit simpler and a tiny bit faster
3. implement proper character validation, i.e. check all digits for validity in the XML sense before handing over to BigInteger/Long; adds performance overhead

[laurentschoelens]

I'm a bit precautionous about that kind of changes that would lead to potential breaking in api (see latest jaxb-api release regarding base64 decoding)

I would just have added all test cases that gets 100% coverage with actual code (and specially with removed function) and see that nothing gets worse with your PR