[Storage] [WebJobs] LogScan new blobs between the start of polling and the LMT of the last LogScan

[amnguye]

Attempt to resolve issue #51030

Where LogScan fails to detect newly created blobs when the List Blobs/Get Blobs operation requires multiple requests. If a blob is added or modified after LogScan begins and during the later portion of the listing, any blobs changed between the listing start time and the last modified timestamp of blobs found later will not be flagged as new in the subsequent LogScan.

[AartBluestoke]

basically the same change as was proposed at Azure/azure-webjobs-sdk#3014 :)
if you are on the first page of data (ie, no continuation token), you can still safely advance the timestamp as high as you want., this will completely preserve existing behaviour for those people unaffected by this bug

1. list blob api call is issued (first page only, no continuation token)
2. blob on page 1 is edited
3. blob on page 1 is edited.
4. response includes blobs edited at 2 and 3.

if it is possible for storage to return blob 3 but not 2, then as written it is correct, we can't advance timepoint past 1.
if storage only returns either none, just 2, or both 2 and 3, then advancing the high water mark to timepoints 2 and 3 to avoid them being also returned in the next call is best (potential double handling is benign as etag filtering will silently drop them).