Some documentation fixes

[Quinn-With-Two-Ns]

Fix the count in ScheduleListEntry

Disallow setting MaxConcurrentWorkflowTaskExecutionSize to one because it doesn't work

Looks like we limit the number of pollers to MaxConcurrentWorkflowTaskExecutionSize so the worker will only be polling on the sticky queue, so it will never pick up work. So the root cause is the same reason we need 2 workflow task pollers
Note: Technically we do create maxConcurrentWorkflowTaskPollers number of pollers , but only really start MaxConcurrentWorkflowTaskExecutionSize
MaxConcurrentWorkflowTaskExecutionSize should never be less than MaxConcurrentWorkflowTaskPollers
We call this out here https://docs.temporal.io/application-development/worker-performance#invariants but say it only applies to java which is not true it also applies to the go sdk from reading the code.
Basically we need to document this and probably force MaxConcurrentWorkflowTaskExecutionSize to be greater than MaxConcurrentWorkflowTaskPollers

This change is technically a breaking change, but their workers were not able to process workflows anyway so seems reasonable.

We could force MaxConcurrentWorkflowTaskExecutionSize to be greater than MaxConcurrentWorkflowTaskPollers theoretically could cause users working workers to panic so I held off on it.

resolves #1003