There are legitimate cases where developers wish to ignore the results of a `StatusWith` returning call. An example is `TaskExecutor::scheduleRemoteCommand`, which returns a `StatusWith< CallbackHandle >` result.

A common use case which benefits from this change is one which needs to schedule background or remote "kill" style commands on that interface during some kind of destruction or shutdown. If the creation of the remote request fails, it doesn't matter, as the request was part of some kind of shutdown (often in case of failure). If the request was successful, the developer doesn't need the actual value result of the `StatusWith`, as there is no need to wait for this operation to complete.

Presently, `StatusWith` has a member `getStatus` which returns the `Status` member by const reference. This means that constructions such as these are necessary to avoid problems:

Status s= executor->scheduleRemoteCommand( request, []( auto ) {} ).getStatus();
std::move( s ).ignore();

or

[]{ return executor->scheduleRemoteCommand( request, []( auto ) {} ).getStatus(); }().ignore();

or

auto result=executor->scheduleRemoteCommand( request, []( auto ) {} ).getStatus();
if( !executor->scheduleRemoteCommand( request, []( auto ) {} ).getStatus().isOK() ) { (void) 0; }

or other similar ugly constructions.

`StatusWith` deliberately lacks an `ignore` member, as it would be unclear to the reader which part of a `StatusWith` was being ignored – the actual return value, or the error-encoding result. Permitting `Status::ignore` to be called from the results of a `StatusWith< T >::getStatus()` call would greatly improve readability:

executor->scheduleRemoteCommand( request, []( auto ) {} ).getStatus().ignore();

This is fairly trivial to implement. I already have a prototype, and a number of people have requested this kind of mechanism.