Fix numeric conversion to Long when serializing numbers as JsonElement tree

[Marcono1234]

Purpose

Fixes #2680

Description

As mentioned in #2680, an unintended side-effect of 3e3266c was that serializing to a JsonElement tree is now converting all integral numbers to Long instances.

This pull request here tries to solve this by using the JsonWriter#value(Number) overload again, boxing the converted number. If the type is already matching (e.g. serializing a Byte as Byte) then this also has the advantage that it avoids unwrapping and having JsonTreeWriter wrap the value again.
But on the other hand when using JsonWriter and not JsonTreeWriter there might be a bit overhead from JsonWriter#value(Number) compared to JsonWriter#value(long).

An alternative to this PR could be to instead revert 3e3266c partially or completely. After all the underlying issue #2156 had been reported by me (and was not blocking me in any way), so maybe other users would not have cared about the missing numeric conversion.

Checklist

• New code follows the Google Java Style Guide
  This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.
  Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
• If necessary, new public API validates arguments, for example rejects null
• New public API has Javadoc
  • Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• If necessary, new unit tests have been added
  • Assertions in unit tests use Truth, see existing tests
  • No JUnit 3 features are used (such as extending class TestCase)
  • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• mvn clean verify javadoc:jar passes without errors

[Marcono1234]

Closed and reopend this PR to fix an intermittent test failure, see #2815.

[Marcono1234]

For correctness this value instanceof Long check is not needed; the previous code which always called out.value(value.longValue()) was fine as well. However, for JsonTreeWriter it would have unwrapped and then wrapped the value again. But on the other hand for JsonWriter value(long) might be more efficient. I am not really sure which approach is better for performance, or if it even matters at all.

(same applies to Double below)