Feat: Add queryId to TableResult

[PhongChuong]

This PR adds queryId to TableResult by changing its public constructors. It should be fine to update TableResult constructors to include QueryId since it is used to return results to the user and users should not directly construct TableResult objects.

• 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 #3105 ☕️

[PhongChuong]

Please let me know if it's not advisable to update the constructor for TableResult.

[tswast]

Please let me know if it's not advisable to update the constructor for TableResult.

I recommend asking on a Java chat. This may be considered a breaking change.

[PhongChuong]

Please let me know if it's not advisable to update the constructor for TableResult.

I recommend asking on a Java chat. This may be considered a breaking change.

Just verified, since the constructors are annotated with
@internalapi("Exposed for testing")
It should be fine to change the constructor.

[shollyman]

Rather than solely extending the existing constructor, should we just provide an second signature or a builder? It would mean you can avoid having to touch all the callsites where queryId isn't relevant for construction.

[PhongChuong]

As discussed offline. I think creating a builder would be the preferred option. I'll follow up with another PR to switch to using a builder.