share: concurrency handling, easy updates

Replace the `volatile int dirty` with a reference counter
protected by a mutex when available.

Solve the problem of when to call application's lock function
by adding a volatile flag that indicates a share has been added
to easy handles in its lifetime. That flag ever goes from
FALSE to TRUE, so volatile might work (in the absence of a mutex).

(The problem is that the lock/unlock functions need 2-3
`curl_share_setopt()` invocations to become usable and there
is no way of telling if the third will ever happen. Calling
the lock function before the 3rd setopt may crash the
application.)

When removing a share from an easy handle (or replacing it with
another share), detach the easy connection on a share with a
connection pool.

When cleaning up a share, allow this even if it is still used in
easy handles. It will be destroyed when the reference count
drops to 0.

Closes #20870

docs/libcurl/curl_share_cleanup.md

@@ -27,7 +27,8 @@ CURLSHcode curl_share_cleanup(CURLSH *share_handle);
 # DESCRIPTION
 
 This function deletes a shared object. The share handle cannot be used anymore
-when this function has been called.
+when this function has been called. The share fails the call if it is
+still being used in any easy handle.
 
 Passing in a NULL pointer in *share_handle* makes this function return
 immediately with no action.
@@ -35,6 +36,11 @@ immediately with no action.
 Any use of the **share_handle** after this function has been called and have
 returned, is illegal.
 
+For applications that use a share in several threads, it is critical that
+the destruction of the share is only done when all other threads have stopped
+using it. While libcurl tracks how many easy handles are using a share,
+it can not observe how many pointers to the share the application has.
+
 # %PROTOCOLS%
 
 # EXAMPLE