Removes more timeout from storage operation builders

[bmc-msft]

With multiple PRs landing one on top of each other, not all of the timeouts as part of the bulider patterns were removed during #893.

These remove all but two that use the Storage crate, both in data_tables.

1. TransactionBuilder. This Builder does not use setters, but instead provides it's own builder methods to enable adding multiple database operations into the single transaction. It does not need the setters portion of the operation macro, but should still be a builder.
2. UpdateOrMergeEntityBuilder. This no longer needs to be a builder, as the only optional field is now handled via aforementioned PR.

In both of these cases, removing the timeout option from the operation causes the macro to fail, as it requires at least one optional parameter.

With TransactionBuilder, I'd prefer the macro be updated to support no optional params if we're providing our own setters.

With UpdateOrMergeEntityBuilder, this probably doesn't need to be an operation, however it's the only operation that doesn't need .into_future, which makes it feel weird from a user's perspective. Once IntoFuture is stable, this could just return a future directly without using the builder pattern.

[rylev]

Let's get this merged, but I have a note about your description of the issue:

In both of these cases, removing the timeout option from the operation causes the macro to fail, as it requires at least one optional parameter.

This is not true. For example:

azure-sdk-for-rust/sdk/data_tables/src/operations/create_table.rs

Lines 6 to 9 in 2671ca1

	operation! {
	CreateTable,
	client: TableClient,
	}

[bmc-msft]

@rylev , I see what lead me to make that mistaken assessment.

The last optional field must not have a comma, while the last required field must have a comma.