add wil::create_file_create, create_file_open, etc. tame use of CreateFileW

[ChrisGuzak]

I distilled the documented behavior of CreateFileW into these helpers with the goal enabling simple use of the functionality without having to construct the long and complicated, and interdependent parameter list.

auto handle = wil::open_file(path.c_str());

The design uses "open", "create" and "trucate" to distinguish the cases that open existing files and use that creates and modifies existing files. Here is more complicated use that demonstrates the handle and error code being returned (used in success cases, so providing access to it is essential.).

auto path = wil::ExpandEnvironmentStringsW<std::wstring>(LR"(%TEMP%\create_file_test.txt)");
auto [fileHandle, error] = wil::try_create_new_file(path.c_str())

Here, are the method names that intend to describe the semantics.

auto handle = wil::create_new_file(path.c_str());
auto handle = wil::open_or_create_file(path.c_str());
auto handle = wil::open_or_truncate_existing_file(path.c_str());
auto handle = wil::truncate_existing_file(path.c_str());

PR includes tests now.

[jonwis]

I'm of multiple minds on this. I like that it's clearing up the "floor wax and dessert topping" form of the API, I don't know that this is the way that's most intuitive in naming for me yet.

[dunhor]

nit: Not critical, but this could be pulled out of the ifdef for exception support

[dunhor]

I'm still of the opinion that flags & attributes should come before security attributes, but otherwise things look good to me