Having local lists for each system will increase memory usage for
classes.
It's a traditional space-time tradeoff.
While iterating through all the entities and checking their signatures is straight to code,
it may become inefficient as your number of systems grow - imagine a specialized system (let it be input) that looks for its probably single entity of interest amongst thousands of unrelated entities.
That said, this approach may still be good enough depending on your goals.
Although, if you're worried about speed, there are of course another solutions to consider.
Should every system hold a local list of entities which they are interested in?
Exactly. This is a standard approach that should give you decent performance and is reasonably easy to implement. The memory overhead is negliglible in my opinion - we're talking about storing pointers.
Now how to maintain these "lists of interest" may not be that obvious.
As for data container, std::vector<entity*> targets
inside system's class is perfectly enough.
Now what I do is this:
Removing an entity is entirely analogous, with the only difference that we remove if a system matches with our current signature (which means that the entity was there) and doesn't match with the new signature (which means the entity should no longer be there).
Now you may be considering usage of std::list because removing from vector is O(n), not mentioning that you would have to shift big chunk of data every time you remove from the middle. Actually, you don't have to - since we don't care about processing order on this level we can just call std::remove and live with the fact that on every deletion we only have to perform O(n) search for our to-be-removed entity.
std::list would give you O(1) remove but on the other side you have a bit of additional memory overhead. Also remember that most of the time you will be processing entities and not removing them - and this surely is done faster using std::vector.
If you are very performance critical, you can consider even another data accessing pattern, but either way you maintain some kind of "lists of interest".
Remember though that if you keep your Entity System API abstracted enough it shouldn't be a problem to improve systems' entity processing methods if your framerate drops because of them - so for now, choose the method that is easiest for you to code - only then profile and improve if needed.