Allow multiple task queues to a worker - enables throttling of specific activities

Is your feature request related to a problem? Please describe.
We need to throttle specific activities across all worker instances to not run more than a number per second. That's to not overload downstream.

Temporal task queues already can be configured to have a limit of activities run per second, so if we could register several task queues (with different limits), we could use specific queues for some activities that need throttling.

Describe the solution you'd like
Ability to attach several task queues to a worker. Each task queue can have it's TaskQueueActivitiesPerSecond configured independently.

worker.New(temporalClient, "your-task-queue-name", worker.Options{})

would now looks something like:

queues := []Queue{{
    "task-queue-fast",
    QueueOptions {
        TaskQueueActivitiesPerSecond: 100000,
    }},
    "task-queue-slow",
    QueueOptions {
        TaskQueueActivitiesPerSecond: 10,
    }},
}

worker.New(temporalClient, queues, worker.Options{})

then calling an activity, you can select what queue to send it to

newOptions := workflow.ActivityOptions{
	TaskQueue:          "task-queue-slow,
}
newCtx := workflow.WithActivityOptions(ctx, newOptions)
err := workflow.ExecuteActivity(newCtx, ThrottledActivity, name).Get(ctx, &result)

Describe alternatives you've considered
Alternatives available:

• have copies of the same worker register to the same task queue - requires several instances of the worker
• do the throttling using an external system - e.g. redis/db etc

Additional context
This is a very common setup which all projects calling downstream API endpoints would be able to use.

I am happy to give it a go at raising a PR for it if you think this is something you'd like to include.

Start by tracing the worker.New entry point and the TaskQueueActivitiesPerSecond option through the worker and workflow activity-routing implementation. Review existing worker and task-queue tests before defining coverage for multiple queues, independent limits, and activity selection; done means each configured queue can throttle separately and activities can target the intended queue.