Improve ergonomics of `Requirement.marker` evaluation

Currently Requirement.marker is of type Optional[Marker], and the following code is needed to check whether a requirement needs to be resolved:

def needs_resolution(r: Requirement) -> bool:
    if not r.marker:
        return True
    return r.marker.evaluate()

which becomes cumbersome quickly. I can think of three ways to improve the interface:

1. Allow Marker('') that always evaluate to True (similar to SpecifierSet('')), and use that to indicate no markers instead of None. This could be a problem if people are checking for marker is None, but I think most of the use cases should also be compatible with evaluate().
2. Similar to 2., but do this with another class EmptyMarker. This has most of the same problems as above, and may also be a problem for people doing isinstance(marker, Marker). Maybe this can be worked around with __subclasscheck__?
3. Introduce a convinience method Requirement.evaluate_marker() that encapsulate the above logic. This is the least disruptive change, but could be a bit confusing.

Start by reviewing the Requirement.marker and Marker.evaluate interfaces described in the issue. Compare the three proposed approaches, including their effects on None checks, isinstance checks, and backwards compatibility. Done when one interface direction is selected and its expected behavior is clearly specified.