Permitting rhs properties in filters

[sauliusg]

Adding grammar rules to the Filter EBNF grammar to permit 'property CONTAINS another_property' constructs, which are described in the specification as optional features.

[merkys]

Am I right to assume that this PR contains all the commits from #160? In this case it'd be better to have #160 merged first. What is more, changes of this PR are not evident due to the same reason.

[sauliusg]

Am I right to assume that this PR contains all the commits from #160? In this case it'd be better to have #160 merged first. What is more, changes of this PR are not evident due to the same reason.

Yes, you are right. I think if I made the changes from the develop branch, then they would be in conflict with changes from #160; I hope that if we merge #160 into the trunk first (once it is accepted), then this PR (#161) should be merged without conflicts (and if #160 is rejected for some reason I can easily modify the changes in #161 to work with the develop, but I guess both #160 and #161 should be OK).

[rartino]

This indeed seems as a grammar bug. Properties really should be allowed on the RHS.

Could you re-base this against the present develop? As I wrote in #160, I think we need more discussion there, but this is a good bugfix to get in for v0.10.

[giovannipizzi]

Also, by rebasing and only applying relevant commits (e.g. squashing multiple ones in only one) we avoid risks of #163 happening again.
The policy should be:

• always branch off the most recent develop for any new PR
• apply (a minimal set of) commits in the new branch
• make a PR

We can always update to the most recent develop before merging, from the GitHub interface.
Only in case of merge conflicts one will have to commit again the fix before merging.