[6.x] Fix the value generated when setting encrypted cookies

[code-distortion]

This PR updates the Dusk Browser object so that it sets encrypted cookies to match the way laravel/framework does.

Without this, setting an encrypted cookie results in an invalid value that Laravel ignores:

$browser->addCookie($name, $value, $expiry = null, array $options = [], $encrypt = true);

For reference, this is where Laravel/Framework encrypts and decrypts cookies:
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Cookie/Middleware/EncryptCookies.php#L147
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Cookie/Middleware/EncryptCookies.php#L86

---

I'm not sure how to go about testing this within this package, as some of the functionality that's used to set cookies isn't available. (eg. the encrypt helper, Laravel's app object, etc).

I have tested this separately in a Laravel installation by using addCookie to set an encrypted cookie, and then make a request to a page that spits out the cookies that were decrypted by the EncryptsCookies middleware.

[code-distortion]

laravel/framework includes the hashed cookie name as a prefix. When reading a cookie value, it ignores it if this prefix is missing.

But it didn't always. Older versions didn't use the prefix at all.

When Dusk reads a cookie's value, it doesn't care if the prefix was added or not. I imagine this is for compatibility reasons: https://github.com/laravel/dusk/blob/6.x/src/Concerns/InteractsWithCookies.php#L38

When Dusk sets a cookie, technically should choose to add the prefix depending on the version of Laravel being used.

Should care be taken here to selectively add the prefix, or is the Laravel change so old that it doesn't matter?

[driesvints]

@code-distortion let's leave the prefix be for now.