REF: avoid mutating Series._values directly in setitem but defer to Manager method
There are currently two cases where the Series code directly modifies the underlying values itself (`self._values[..] = ..`), while most setitem code paths end up going through a specific indexing method that all end up in the Manager doing the actual modification of the values.

Apart from being a bit inconsistent (it's good to have all eventual modifications consistently happening inside the manager, I think), I also need to move this to the manager for being able to check for copy-on-write in https://github.com/pandas-dev/pandas/pull/41878. 
Since I think this is a generally useful change, moving it out of the CoW PR.
I lean towards using a new method instead of overloading `setitem`, which in general can cast. > let's try not to overload setitem (e.g. its always inplace), so not in place is odd.

@jreback to be clear, it's the existing manager `setitem` method that is _not_ inplace (the odd thing), and I am adding a variant that _is_ inplace .

> I lean towards using a new method instead of overloading setitem, which in general can cast.

I can certainly add a new method (eg `setitem_inplace(..)`) instead of adding a keyword (`setitem(.., inplace=True)`), no problem. But just note that this is really doing the same operation. It's just that in some cases, we know that the setitem will in practice be inplace, and we can be stricter in that case by not going through the general Block method that indeed can cast (that optimization was now done inside Series, and this moves it to the manager). Given that it is about the same operation but with different semantics, I think a keyword actually makes sense. The last commits adds the version with a separate method instead of keyword. Either way is fine for me (it's also easy to revert) BTW im picky on the implementation, but in general i think this is a very good idea Any further response here? i will look at some point This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. This is not stale, but waiting on further comments. i think the failures are related here, e.g. the stacklevel is changed. so prob need to use `find_stack_level` instead of hard-coding for a lot of the indexing tests. > i think the failures are related here, e.g. the stacklevel is changed. so prob need to use `find_stack_level` instead of hard-coding for a lot of the indexing tests.

actually these are likley https://github.com/pandas-dev/pandas/pull/42857

but this PR may affect as well (so let's fix that one first)