Adding Exclude property to DoubleRangeFilter and test coverage.

[HazWard]

What this PR does / Why we need it:
This set of changes gives more control over the excluded/included bounds of DoubleRangeFilters.

Which issue(s) this PR fixes:

Closes #1260

Special notes for your reviewer:

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[adumovic]

@googlebot I fixed it

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Laremere]

PR mostly looks good, I would still prefer bools over having the enum, is there more reasoning behind choosing the enum? See comments in: #1260

[Laremere]

CLA issue is because of the email HazWard@users.noreply.github.com

[Laremere]

Git amend the PR with your Unity email to fix, I think. (and if possible, set that as your default github email would avoid this problem, I think?)

[HazWard]

Thanks for the tip, I did the merge from the website so it didn't use my work email.

[HazWard]

We went with enums because we use them often and it gave us a single fields to indicate which bounds should be excluded.

[Laremere]

I still don't see full test coverage - given that you've moved and (mostly) copied 1 line of logic behind a switch statement with 4 clauses, full coverage implies there to be roughly 4 times the number of tests. I've thought about it more, and suggest grouping by the case, eg:

`
simpleDoubleRange("minIsNan", 5, math.NaN(), 10, pb.DoubleRangeFilter_NONE),
simpleDoubleRange("minIsNan", 5, math.NaN(), 10, pb.DoubleRangeFilter_MIN),
simpleDoubleRange("minIsNan", 5, math.NaN(), 10, pb.DoubleRangeFilter_MAX),
simpleDoubleRange("minIsNan", 5, math.NaN(), 10, pb.DoubleRangeFilter_BOTH),

simpleDoubleRange("maxIsNan", 5, 0, math.NaN(), pb.DoubleRangeFilter_NONE),
simpleDoubleRange("maxIsNan", 5, 0, math.NaN(), pb.DoubleRangeFilter_MIN),
simpleDoubleRange("maxIsNan", 5, 0, math.NaN(), pb.DoubleRangeFilter_MAX),
simpleDoubleRange("maxIsNan", 5, 0, math.NaN(), pb.DoubleRangeFilter_BOTH),

`
(empty line between the groupings)

The cases which are affected by the enum would become obvious, as there won't be full groupings. The names don't strictly need to be different, though it'd probably be helpful for the cases which are different.