Sharp: toBuffer() without parameter returns ambiguous result (buffer/object) if toBuffer() is used previously

[MihalySzabo]

If I use toBuffer() without any parameters, it returns a promise with a buffer parameter. That is the expected behaviour. If I use it with { resolveWithObject: true } parameter, then it returns a promise with an object parameter, again, that is the expected behaviour. But if I use it with the parameter and then use it without any parameter, the second call also returns a promise with an object, instead of a plain buffer.

What is the output of running npx envinfo --binaries --languages --system --utilities?

```
System:
OS: macOS 10.14.6
CPU: (4) x64 Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
Memory: 94.21 MB / 8.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 8.10.0 - ~/.nvm/versions/node/v8.10.0/bin/node
Yarn: 1.16.0 - /usr/local/bin/yarn
npm: 5.6.0 - ~/.nvm/versions/node/v8.10.0/bin/npm
Utilities:
Make: 3.81 - /usr/bin/make
GCC: 10.14. - /usr/bin/gcc
Git: 2.20.1 - /usr/bin/git
Languages:
Bash: 3.2.57 - /bin/bash
Perl: 5.18.4 - /usr/bin/perl
PHP: 7.1.23 - /usr/bin/php
Python: 2.7.10 - /usr/bin/python
Ruby: 2.3.7 - /usr/bin/ruby

What are the steps to reproduce?

Load an image
Use `image.toBuffer({resolveWithObject: true}).then(function (result) {...})`
Then use `image.toBuffer().then(function (result) {...})` (without parameter) again.

What is the expected behaviour?

Second result should be a buffer instead of an object, because second `toBuffer()` was called without any parameter.

Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?

To get it work, a JPEG image called `image.jpg` have to be in the same directory.

const Sharp = require('sharp');
const fs = require('fs');

var image = Sharp(fs.readFileSync('./image.jpg'));
return image.png().toBuffer({
resolveWithObject: true
}).then(function () {
return image.png().toBuffer().then(function (output) {
console.log(output);
});
});
```

[lovell]

Hi, thanks for the report, happy to accept a PR with the fix and a test that would have caught this if you're able.

You can work around this for now by passing { resolveWithObject: false } to the second invocation

[lovell]

v0.23.1 now available with the fix from PR #1860.