fix: Make sure outstanding RPCs count in ChannelPool can not go negative

[blakeli0]

fixes: #2081

Add two flags wasClosed and wasReleased to ReleasingClientCall to check various scenarios. The combination of these two flags can make sure the count of outstanding RPCs can never go negative, and help us identify what exactly goes wrong next time it happens.

More background for the purpose of outstandingRPCs

The primary purpose of keeping a count for outstanding RPCs is to track when a channel is
safe to close. In grpc, initialization & starting of rpcs is split between 2 methods:
Channel#newCall() and ClientCall#start. gRPC already has a mechanism to safely close channels
that have rpcs that have been started. However, it does not protect calls that have been
created but not started. In the sequence: Channel#newCall() Channel#shutdown()
ClientCall#Start(), gRpc will error out the call telling the caller that the channel is
shutdown.
Hence, the increment of outstanding RPCs has to happen when the ClientCall is initialized,
as part of Channel#newCall(), not after the ClientCall is started. The decrement of
outstanding RPCs has to happen when the ClientCall is closed or the ClientCall failed to
start.

[meltsufin]

I'm not sure if all of these logs should be warnings, but I think the safeguards make sense.

[sonarcloud]

[gapic-generator-java-root] SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

61.1% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[sonarcloud]

[java_showcase_integration_tests] SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

44.4% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint