@beat decoration logging and resolutions

[MarcelWilson]

I've been noticing resolutions will log their beat message but then redundantly also log the retval from the resolution.resolve.

Marcel sees if the username field is visible.
    Marcel inspects the username field.
        => <None>
    ... hoping it's visible.
        => the element is visible

The ... hoping it's visible. and the => the element is visible are communicating the same thing. I believe the resolve methods dont really need to log the return value.

The current behavior also can lead to confusion. We note that the question returned <None> but the resolution logging can make it seem as if the element not only was present, but was also matched; when in fact, it was not.

[MarcelWilson]

This might tie closely with #113 in that beat may need to accept parameters that dictate behavior. Or perhaps we need to create a couple of new variations of pacing decorators for different situations.

[MarcelWilson]

The problem with the logging being confusing is because the __str__ method on BaseMatchers always uses the describe_to.

I think the most likely option is we simply dont log the return value on resolve methods. Or we should consider updating represent_prop use the __repr__ for matchers instead.

Marcel sees if the username field is visible.
    Marcel inspects the username field.
        => <None>
    ... hoping it's visible.
        => <IsVisibleElement(the element is visible)>