Bug Report

Describe the bug

Cloudinary url consists of some parts like <delivery_type>, <asset_type> or <signature>.

(https://cloudinary.com/documentation/transformation_reference).

After library analyzes I found out that the next-cloudinary library has a bug when parsing url:
It expects an url with signature part having only s-- as prefix and then only letter or number ((?s--[a-zA-Z0-9]+--)).
Official library from cloudinary, CludinaryDotNet SDK allows special characters (not only letters or numbers) after s-- prefix. This causes generation of signatures accepted by CloudinaryDotNet SDK, but not accepted by next-cloudinary.

Next-cloudinary with REGEX_URL const:
https://github.com/colbyfayock/cloudinary-util/blob/42ac22fcb1ffbf59c5020c4c7eb7347721f97db4/packages/util/src/lib/cloudinary.ts

CludinaryDotNet SDK with tests allowing special characters in signature part:
https://github.com/cloudinary/CloudinaryDotNet/blob/master/CloudinaryDotNet.Tests/Asset/SignatureTest.cs

Steps To Reproduce the error

1. Create some DotNet backend that generates urls with signatures using CloudinaryDotNet SDK for it.
2. Create some react app using CldImage component and try to use url genarated from the first step. Make sure it has special characters after s-- prefix in its signature part - because, still an url that works is possible.
3. CldImage will do an http call with some weird url (doubled domain and transformations part), the response will be 404.