#58
"Comparing object with "hasOwnProperty" keys fails"

Fixes #58.

Previously, the code assumed that input objects have a `hasOwnProperty`
function, or that at least they will acquire one when passed through
`utils.properObject`.

However, this assumption is flawed:  As noted in issue #58, when given
input objects have a property on them called `hasOwnProperty`, it
overrides the prototype's function property that the code relied on,
causing any diffing function to error out with

    Uncaught TypeError: r.hasOwnProperty is not a function

The solution taken here is to forget about `utils.properObject`, and
instead introduce `utils.hasOwnProperty` which uses
`Object.prototype.hasOwnProperty.call` instead of assuming anything
about the input object, and replacing all direct
`inputObject.hasOwnProperty` calls with it instead.

The way to prevent issues like #58 is not obvious, and I would expect
not all programmers to have memorised the contents of
`Object.prototype`, so I think it would be prudent to check for such
issues automatically.

The no-prototype-builtins rule is enforced automatically by the set of
rules enabled in `.eslintrc.json` by

    "extends": "eslint:recommended"

It's a great sign that all the other enabled rules also pass without
modifications!

I've added the eslint invocation to `package.json`'s `posttest` field.
This should make the check minimally intrusive while developing, as it
will only run when the functional tests (via `jest`) pass first.