Refactor, fix, and optimizer filters/rules

[dsblank]

This PR does three things:

1. Unrolls the recursive call of filter.apply(), and splits out single checks into filter.apply_to_one()
2. Uses JSON data where possible, passing the data rather than objects. If an object is needed, it will not be recreated more than once.
3. Adds an optimizer based on rule.map sets

[dsblank]

The only downside is that we leak the internal representation of the objects into the higher layers of code.

For many attributes of an object, it isn't so much "internal" now that we are switching to JSON. For example, this is the Person object API to get the parent family list:

person.parent_family_list # object attribute
person.get_parent_family_handle_list() # function call

With the above DataDict (with some additional code) with new JSON, it could look like (where person is really JSON data with a wrapper):

person.parent_family_list  # JSON access
person.get_parent_family_handle_list() # function call, instantiates object

The new version would hide the fact that the function call creates the object (but just once). So because the JSON data mirrors the actual attribute names, it doesn't have to change at all.

[dsblank]

Created a PR #1824 to explore attribute access of the JSON dict.

[dsblank]

I'll update this PR to use new DataDict attribute access to dict. Which will actually revert most of the data access to what it is in master.

[dsblank]

@Nick-Hall, I want to refactor this PR based on the DataDict from #1824. Should I change the base branch to #1824, or wait until it is merged?

[Nick-Hall]

I have reviewed and merged PR #1824. Normally we would wait longer to give people longer to comment, but in this case the PR was related to existing work so I made an exception.

[dsblank]

Thank you!