feat: add manual wrapper for v1beta2 read client

[tswast]

We got a bit lucky in that the reader module doesn't create any proto objects, so it could be reused without modification from the "v1" endpoint. Maybe we should be defining these in a shared module that doesn't include the version information, though?

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

[tswast]

Kokoro failure:

    def test_snapshot(client, project_id, table_with_data_ref, bq_client):
>       before_new_data = types.Timestamp()
E       AttributeError: module 'google.cloud.bigquery_storage_v1beta2.types' has no attribute 'Timestamp'

I think there's a manual synth.py config for adding these types from the core protobuf. Will need to add before merging this PR.

[tswast]

Re: AttributeError: module 'google.cloud.bigquery_storage_v1beta2.types' has no attribute 'Timestamp', the v1 API has a handwritten module https://github.com/googleapis/python-bigquery-storage/blob/master/google/cloud/bigquery_storage_v1/gapic_types.py which adds these.

@plamut Was this just for backwards compatibility? I imagine I could use the protobuf/proto-plus well-known type logic here instead.

[plamut]

@tswast Since I was not that familiar with this library and short on time, I think I included these generated types like that to avoid import errors and unblock the microgenerator transition. I didn't explore if there exist dedicated synth settings for the proto-plus types, but instead simply adjusted the existing logic for injecting the (old) protos.

[tswast]

This is ready for review. I used some parameterized test fixtures to keep from duplicating code in the system tests. Next, I'll start looking more closely at what needs to be done for the write client.