HTTP paths might be misinterpreted with extended filename options

HTTP paths used with network based filesystems (managed by the GDAL vsicurl filesystem handler) can be misinterpreted with extended filename options.

Typically, here is an example with some S2 image from the Microsoft Planetary Computer.

otbcli_ReadImageInfo -in "/vsicurl/https://sentinel2l2a01.blob.core.windows.net/sentinel2-l2/11/S/LT/2022/09/25/S2A_MSIL2A_20220925T183121_N0400_R027_T11SLT_20220926T130320.SAFE/GRANULE/L2A_T11SLT_A037919_20220925T183448/IMG_DATA/R10m/T11SLT_20220925T183121_B03_10m.tif?st=2022-10-04T18%3A40%3A54Z&se=2022-10-05T19%3A25%3A54Z&sp=rl&sv=2021-06-08&sr=c&skoid=c85c15d6-d1ae-42d4-af60-e2ca0f81359b&sktid=72f988bf-86f1-41af-91ab-2d7cd011db47&skt=2022-10-05T17%3A12%3A04Z&ske=2022-10-12T17%3A12%3A04Z&sks=b&skv=2021-06-08&sig=gPEfAaAnyTXmXbutH76BVbyyXDqhqMfEwLwRL6BxzEo%3D"

The command above fails because the otb::ExtendedFilenameToReaderOptions believes that everything after the first ? character is some extended filename option. Before failing, it throws many warnings for each "key" it has collected ("se", "sp", "sv", "skoid", etc).

? chars are commonly used in HTTP links, and this issue will likely affect other network based systems, in particular when some token have to be passed in the URL.