String dtype: still return nullable NA-variant in object inference (`maybe_converts_object`) if requested
The `lib.maybe_converts_object()` function (which is used for object dtype inference in various places) has a `convert_to_nullable_dtype=Flase/True` keyword to control whether to return dtypes using NA or not.  Currently we were giving the future `infer_string` option priority. But also when the future dtype is enabled, we should still return an NA-variant of the dtype if explicitly asked for. So this PR switches the order of those two checks to let the `convert_to_nullable_dtype` keyword take precedence over the option.

This came up in SQL tests, but actually this also impacts the `pd.array(..)` behaviour. Currently on main, `pd.array(["some", "strings"])` will infer the nullable `StringDtype()`, consistent with the other dtypes that have such a nullable variant (i.e. returning our Int64 instead of np.int64 for integers, etc). 
This is tested behaviour, but we were still xfailing those tests when `future.infer_string` was enabled. With the change in this PR, also in the future `pd.array(..)` will infer the NA-variant.



(sidenote, we should update this simple `convert_to_nullable_dtype` True/False flag to something that allows passing whether we want a numpy_nullable or pyarrow array, but that's for a separate issue) 
> (sidenote, we should update this simple `convert_to_nullable_dtype` True/False flag to something that allows passing whether we want a numpy_nullable or pyarrow array, but that's for a separate issue)

I think generally should just stick with `dtype_backend` throughout right? Not sure where we go from one to the other but that seems like a lossy move Thanks @jorisvandenbossche 