Remove support for SAS tokens in Tables to encourage SFI best practices

[ahsonkhan]

Based on offline discussion with @JeffreyRichter and @gearama, and SFI guidance, we can remove the AzureSasCredential ctor overload and wait for customer requests for it before adding it. For security best practices, we'd want to steer customers to the pit of success.

Consider removing this ctor along with any other types that would no longer be needed as a result. Leveraging expertise as the SDK owner, we'd want to validate that no known customer scenario is blocked when we do this.

azure-sdk-for-cpp/sdk/tables/azure-data-tables/inc/azure/data/tables/table_client.hpp

Lines 91 to 104 in b391d65

	/**
	* @brief Initializes a new instance of tableClient.
	*
	* @param serviceUrl The service Url
	* @param credential The SAS credential used to sign requests.
	* @param tableName The name of the table.
	* @param options Optional client options that define the transport pipeline policies for
	* authentication, retries, etc., that are applied to every request.
	*/
	explicit TableClient(
	const std::string& serviceUrl,
	std::shared_ptr<Azure::Data::Tables::Credentials::AzureSasCredential> credential,
	const std::string& tableName,
	const TableClientOptions& options = {});

For example, this means, we'd no longer have callers for NamedKeyCredential or the SAS builder helpers, so we can remove them as well (for now). They can always get added back in the future, but we can't take them away if we GA with them.

azure-sdk-for-cpp/sdk/tables/azure-data-tables/inc/azure/data/tables/credentials/named_key_credential.hpp

Line 23 in b391d65

class NamedKeyCredential final {

Related: #6143