Deprecate and replace Guava-using APIs in ContainersStateFactory and its dependencies

[HannesWell]

Also replace Guava where it is simply possible.

Part of #2975

[HannesWell]

I wonder if it is necessary to keep these protected methods as deprecated?
Are custom sub-classes of PathTraverser something that should be supported?
If yes, it should probably also be ensured that these deprecated methods are still called in order to not make custom implementation dysfunctional.

The same applies for Reader and RuntimeResourceSetInitializer adjusted in this PR.

[LorenzoBettini]

Even in this case, I have the same perplexity I expressed in #2978

My suspects might be proved by the fact that you have to add an explicit cast when you call the new method from the deprecated one when passing a lambda expression.

[szarnekow]

Previous usages of container2URIs would never return null when queried via get(someHandle). getContainedURIs might need refinedment.
Into the bargain, it used to be possible to add items to the collection returned from getContainedURis and the changed would be reflected in the containers state, regardless of the fact whether the containers was initially known or not.
We don't (ab)use that detail in the framework, but I'm not a fan of the subtle change nor of the effort we'd need to put into retained that behaviro without using Guava Multimaps.

[HannesWell]

Previous usages of container2URIs would never return null when queried via get(someHandle). getContainedURIs might need refinedment.

I adjusted getContainedURIs to reflect that, i.e. to return container2URIs.getOrDefault(containerHandle, Set.of());.

As a side-note, for uri2container.get(uri) the result was already checked for null before.

Into the bargain, it used to be possible to add items to the collection returned from getContainedURis and the changed would be reflected in the containers state, regardless of the fact whether the containers was initially known or not. We don't (ab)use that detail in the framework, but I'm not a fan of the subtle change nor of the effort we'd need to put into retained that behaviro without using Guava Multimaps.

I would call this an undesired implementation detail on which callers shouldn't rely on. Furthermore the documentation of this class states

xtext/org.eclipse.xtext/src/org/eclipse/xtext/resource/containers/ResourceSetBasedAllContainersState.java

Lines 25 to 26 in 9e3b1b4

	* This implementation {@link IAllContainersState} associates resource (e.g. their URIs) to containers. It assumes that
	* all URIs and their containers are known when {@link #configure(List, Multimap)} is called.

According to this contract it would not be allowed to add elements. And as a third point, adding elements to a value collection of container2URIs, would mean that it goes out of sync with uri2container.
For now I have made the value Sets immutable in order to enforce consistency here. Although this might break the previously possible (ab)use scenario you described.