Add support for policy objects

[qha]

Fixes: #316

[TjeuKayim]

I tested this pull-request, and it is functional. Only minor issues that I could work around. Good how you made it fit in nicely with the rest of the module.

[qha]

Thank you for your review! I will work on the issues you spotted but it might take a few weeks as i've dug down in some other projects...

[qha]

As you might have seen i've addressed the issues you spotted but i won't have time to test them properly until some time in august at best.

[qha]

I just did some real life testing and things seem to work as expected.

I've squished my fixes and rebased on master to remove the merge conflict.

After rebasing the spec tests report an error on my workstation but i don't think it's related as the same error is present in the master branch.

[qha]

Sorry, i need to fix another thing. The firewalld_policy type insists that ingress and egress zones are arrays which is normally resonable but i don't think it is when ensure is absent.

[qha]

There, ingress_zone and egress_zone may now be emtpy if ensure is absent.

[jcpunk]

Can I help get this ready for merge in?

[jcpunk]

@qha can you squash this down again?

[qha]

Sorry for being so slow to respond, i was busy going to and recovering from a conference.
If i'm supposed to squash my changes into some other combination of commits i would need more detailed specifications as i feel the current partitioning is the most appropriate and the remote second should be available to whoever merges this with two clicks (squash and merge).
@jcpunk

[jhoblitt]

Would adding the #instances method to the provider(s) be an alternative to this to allow purging of unmanaged resources?

[qha]

Perhaps i would have known while this was fresh in my mind but i don't now. I hope someone else can answer this.

[jcpunk]

The main squashing I had in mind was regarding the readme and reference updates. Having the parameter name tweaks in a separate commit may or may not add clarity.

[qha]

I see. If i recall correctly i did it that way because the reference had not been updated the last few commits so updating it introduced unrelated changes that i did not want to put in the same commit.
Would it help if i updated the reference before the main commit in this pr in one commit and then did so again as part of the main commit?

[jcpunk]

I see. If i recall correctly i did it that way because the reference had not been updated the last few commits so updating it introduced unrelated changes that i did not want to put in the same commit. Would it help if i updated the reference before the main commit in this pr in one commit and then did so again as part of the main commit?

That is fine with me

[qha]

I see. If i recall correctly i did it that way because the reference had not been updated the last few commits so updating it introduced unrelated changes that i did not want to put in the same commit. Would it help if i updated the reference before the main commit in this pr in one commit and then did so again as part of the main commit?

That is fine with me

I can't find the other changes i thought i remembered so i just squashed the last commit into the main one.

[jcpunk]

Unless there are any objections I'd like to merge this in next week.