[service-bus] Implement handling for subscribe() after closing a subscription.

[richardpark-msft]

As part of #9802 we now allow the user to close() the result of a subscribe().

This introduces a new partially-closed state that we didn't have before:

Old:

const receiver: Receiver;
receiver.subscribe();
// no way to stop the subscription except....
await receiver.close();

Now:

const receiver: Receiver;
const subscription = receiver.subscribe();

await subscription.close();     // does not close the receiver link, but does drain the receiver

// hey, can I subscribe again?
// receiver.subscribe() throws an error here about only having one active subscription at a time per receiver.

await receiver.close();   // actually closes the link

The issue that @ramya-rao-a has brought up is that the user might then be tempted to just .subscribe() again (after all, they've 'closed' the other subscription). This does not work today because our old check logic assumed that the user could only have one active subscribe at a time.

A couple of options:

1. Eliminate the restriction on the user having only one subscribe() at a time. It follows logically that the user can just subscribe() and subscription.close() whenever they want. We can still track all outstanding links associated with the receiver and just shut them down (ie, 1 is the same as 'n' from the internals).
2. Carve out a hole so a user can call subscribe() again so long as the old subscription was close()'d. This would still enforce the "only one active subscription at a time" restriction if we think that's necessary.

#1 is my preference - although there is some possible utility is trying to limit users to creating only a single instance each of a batching/streaming receiver there isn't any particular reason to enforce it (users can get the same behavior by just calling it once).