Expose partitioning, max entity size and HierarchyNamespaceOptions

[andreasohlund]

This PR exposes a small set of additional Azure Service Bus transport settings on AzureServiceBusServerlessTransport so Azure Functions endpoints can configure the same infrastructure/topology concerns that make sense in the Functions hosting model.

Changes

• Added same-name pass-through properties on AzureServiceBusServerlessTransport for:
  • EnablePartitioning
  • EntityMaximumSize
  • HierarchyNamespaceOptions
• Added XML docs describing the Functions-specific semantics of each setting
• Updated the transport settings convention approval so these properties are explicitly treated as mapped
• Updated the public API approval for the Azure Service Bus component
• Added focused tests covering the new passthrough properties

Rationale

EnablePartitioning and EntityMaximumSize are relevant in Azure Functions because the transport can still create infrastructure on startup, just like the regular Azure Service Bus
transport. Exposing them keeps the serverless transport aligned with that behavior and with the already-exposed AutoForwardDeadLetteredMessagesToErrorQueue setting.

HierarchyNamespaceOptions is also a good fit, but for a slightly different reason: it not only influences infrastructure setup, but it also has runtime effects because it shapes the queue
names, topic names, and transport destination resolution.

[andreasohlund]

Tested HierarchyNamespaces and it works as expected.

To configure, users would have to:

1. Configure their triggers with the correct prefix: (note the development/ in the queue name)

  [Function("BillingBackend")]
    [NServiceBusFunction]
    public partial Task BillingBackend(
        [ServiceBusTrigger("development/billing-backend", Connection = "AzureWebJobsServiceBus", AutoCompleteMessages = false)]
        ServiceBusReceivedMessage message,
        ServiceBusMessageActions messageActions,
        FunctionContext functionContext,
        CancellationToken cancellationToken = default);

2. Configure the transport:
   new AzureServiceBusServerlessTransport(TopicTopology.Default) { HierarchyNamespaceOptions = new HierarchyNamespaceOptions { HierarchyNamespace = "development" } }

[danielmarbach]

For me, tests like that are usually of very little value because you can literally review the code to spot errors. That being said, I'm also not opposed to keeping it.