feat: Multi db test parametrization

[Mariatta]

The changes are:

• adding test parametrization wherever the client is used. It will run the test against the default db, and a named db named db can only be passed to the Client, and the underlying queries and aggregation queries will retrieve the database id from the Client.

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:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

[kolea2]

I dont think the ITs were run since this is a draft PR - can we convert to ready for review?

[kolea2]

it would be great to add one additional test without parameterization testing client initialization with:

1. not setting the database
2. setting the database
3. setting the database to None

and asserting the database is set correctly.

[vishwarajanand]

@kolea2 there are 2 approaches to tackle this:

1. (current - neater approach but tests only client initialization) Adds test_client_constructor_without_db where DB isn't set and the database is asserted to equal DEFAULT_DATABASE

2. (Code become less readable, but tests are more exhaustive) we can add a check in _make_default_client to not use database param when it's an empty string during the client initialization.

I choose the first approach for readability, but I have no qualms with the second one too. Leaving this comment open for now for Python reviewers.

[kolea2]

lgtm, will defer to @googleapis/yoshi-python for the remaining review!