Add panic-safe TrySubmit and TrySubmitWait with backward compatibility.

[Jagerente]

This PR introduces new methods TrySubmit and TrySubmitWait to provide a panic-safe way to submit tasks to the worker pool, providing clear and explicit way for users to handle the stopped state of the worker pool without breaking backward compatibility by changing existing behavior in a non-obvious for users way.

• Tests have been added.
• Examples and usage documentation for the new methods have been added to the README.

Note:

• The problem covered by this changes was noted earlier in Race between Submit and Stop #76.
• There is also suggested solution provided in fix for channel to be closed gracefully #66, however IMHO it is not good, because it alters existing behavior in a non-obvious way where tasks might not be executed as expected, but instead become no-ops. So it's better to panic than do nothing in that case.

[gammazero]

Seems there is a race here: If WorkerPool is stopped after the p.Stopped check, but before the call to p.Submit. Consider using recover and checking for a write to a closed channel error, and then returning ErrWorkerStopped.

[gammazero]

I was thinking of something like this: https://github.com/gammazero/workerpool/pull/80/files, but...

Really, I want workerpool.Submit to behave like sending a task to a goroutine over a channel, which is really all it is doing but in a limiting way. If that channel was closed sending to it would panic, any I want workerpool to behave the same way.

If a caller needs to handle the panic and return an error or ignore it, then they can easily wrap the channel send or the call to workerpool.Submit from inside a function that recovers from the panic and does error handling. Since this is trivial to do, it does not need to be in this library, and the caller can handle handle the panic if they want..

[gammazero]

Suggested change

	case <-ctx.Done():
	case <- time.After(100 * time.Millisecond):

Simpler to not create a context for the timeout.