Update all path buffers to accept long UNC paths

[JeffryBooher]

• FIxes appshell.fs.showOpenDialog: Windows wchar_t buffer is too small brackets#5270

[bchintx]

@redmunds I noticed that there were merge conflicts w/ my other pull request. So, I took the liberty of updating this branch as well, so that it can be Merged.

[redmunds]

Thanks.

[redmunds]

@JeffryBooher This change increases the buffer size from 260 to 4096 which allows brackets-shell to handle longer file paths.

But the bug report states: "... the buffer should be large enough to accommodate collections of paths. In my particular installation, I needed to support several thousand file selections to deal with image sequences."

Does this add support for collections of paths that support "several thousand file selections" as requested in the bug?

[njx]

I wonder what the use case for selecting a thousand files in the Open dialog is...seems a bit outside our wheelhouse.

[redmunds]

@njx I'd like to get feedback from original filer about a usage scenario, but I think this should probably be merged to get the longer file paths. Agreed?

[njx]

Yup, I definitely think this makes sense to merge--was just thinking that we don't really need to generalize it for the "thousands of paths" case yet until we understand why that's valuable.

[redmunds]

Looks good. Merging.

[JeffryBooher]

@redmunds @njx this change works
For collections because the File
Open dialog uses a null terminated strings in the buffer to delineate each entry and a double null to terminate the string. The first entry is the path followed by each individual file name selected so it doesn't blow out the buffer size requirements to handle multiple file selections. Hipefully this is big enough to handle most cases.