Refactor find_answer

[imobachgs]

Problem

While checking the answers module, I discovered we were using a labeled for. That's perfectly fine, but coming from Ruby I felt that we could use a higher-level approach.

I took it as a refactoring exercise given that the original implementation was OK.

Solution

• Move the logic to determine whether an answer responds to a question (just moving that code to a different function allows us to avoid the nested for). Moreover, I think the logic belongs to Question or Answer.
• Replace the for structs with calls to find and all, as they express the intention better.
• Import (use) the GenericQuestion to avoid spelling the whole module name (agama_lib::questions::GenericQuestion vs GenericQuestion). If tomorrow we decide to change the GenericQuestion to a different place, we need to update all the references. Not to mention that the lines are rather long and harder to read.

Testing

• The module has quite some tests (thanks!) and they pass.

[imobachgs]

Alternatively, we can write:

Suggested change

	if !question.class.eq(class) {
	if question.class != *class {

It looks more natural to me, wdyt?

[mvidner]

in that case, also do it for question.text below

[imobachgs]

Yes, an even for e_val.eq(value) below.

[coveralls]

coverage: 72.07% (-0.009%) from 72.079% when pulling 7848121 on imobachgs:refactor-find_answer into 57d328b on openSUSE:master.

[mvidner]

Makes sense, thanks!

[teclator]

LGTM