Clarify FileShare enum descriptions to remove ambiguity Fixes #10572

[oii-nasif]

Summary

• Removed misleading word "subsequent" from all FileShare enum member descriptions
• Clarified that FileShare flags control access for all file operations, not just future ones
• Updated descriptions for Delete, Read, ReadWrite, and Write enum members

Details

The original FileShare enum documentation used the word "subsequent" in descriptions like "Allows subsequent
opening of the file for reading", which incorrectly implied that these flags only affect future file open attempts
after the current one.

In reality, FileShare flags control whether any attempt to open the file (including the current one) will
succeed, based on how existing file handles were opened. This was demonstrated in issue #10572 with this example:

using var fileStream1 = new FileStream("test.file", FileMode.OpenOrCreate, FileAccess.Write, FileShare.Read);
using var fileStream2 = new FileStream("test.file", FileMode.Open, FileAccess.Read, FileShare.Read);

The second open fails because the first handle has Write access, even though both specify FileShare.Read. The
original documentation's use of "subsequent" made this behavior unclear.

Changes

• Delete: "Allows subsequent deleting" → "Allows the file to be deleted by this process or other processes"
• Read: "Allows subsequent opening for reading" → "Allows the file to be opened for reading by this process or
  other processes"
• ReadWrite: "Allows subsequent opening for reading or writing" → "Allows the file to be opened for reading or
  writing by this process or other processes"
• Write: "Allows subsequent opening for writing" → "Allows the file to be opened for writing by this process or
  other processes"

Fixes #10572

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io