feat!: [Datastore] Upgrade to V2

[yash30201]

Main PR for all the Datastore PHP v2 upgrade changes as mentioned below:

• Enable direct Gapic Client instantiation in Google\Cloud\Datastore\DatastoreClient 7215b2e
• Add credentials wrapper support in DatastoreClient 237531f
• Instantiate serializer and Request Handler in DatastoreClient. cac76f1
• Update Resource classes to add serializer and requesthandler in their constructor. f39189f
• Update all the Snippet and Units tests to add $requestHandler prophecy and serializer be2533c
• Update Client + ResourceClass methods to use request handler for everything, correspondingly, update their unit tests and snippet tests.
  • BeginTransaction and AllocateIds RPC: d06abf7
  • Lookup RPC: cee1539
  • RunQuery RPC: 927d510
  • RunAggregationQuery RPC: c9d2186
  • Commit RPC: 82716bd
  • Rollback RPC: fcdcf9b
• Remove all references of connection classes from everywhere 4c32fc9
• Update System tests [Not needed as none of the tests broke🎉]
• Add MIGRATING.md file e098d66
• Update DatastoreClient's documentation 2196aa2
• Remove old GAPIC files (class aliases, etc) 0596f27
• Increase minimum core to ^1.55 bf2c50b
• Mark Operation class as internal d6e2823

BREAKING_CHANGE_REASON=RC-1 for the version 2 of the Datastore library.

[bshaffer]

I'll give this a more thorough review later today, but don't forget we need to remove all V1 GAPIC client classes. For Datastore V1, that would be Datastore/src/V1/DatastoreClient.php and Datastore/src/V1/DatastoreGrpcClient.php.

Also the PR title should be renamed to better describe what the PR is doing. For PubSub, we said "remove connection classes". I don't mind using V2 in the title (since we are bumping to a V2 version), but we do not need to include PHP in the title.

[bshaffer]

Looks good! A few suggestions with testing and some other minor things. The bigger question I have is with the Operations class - it looks like we are doing a LOT of converting of parameters. Why is so much of this necessary? Since we are doing a major version break, we have an opportunity to clean this up. Parameters which need to be changed should fall in two categories:

1. We think the current (non-standard) interface is better. This would include things like accepting the string values of constants instead of their int versions. And since we know which parameters are enums, we could even automate this for all parameters (something to consider, but maybe not a good idea)
2. We think the GAPIC interface is better. These should then be deprecated and either removed entirely (if they are not heavily used parameters) or renamed/converted to their new parameter/type.

[bshaffer]

Shouldn't this logic be in a Serializer class? This makes me a bit nervous, because changes to these parameters will break the API...

Is there a generic way we can do this logic? For instance, Message::serializeToJsonString will handle string enums (e.g. "AND" and "OR")