Change INF for echo sample to comply with new InfVerif requirements.

[NateD-MSFT]

Using preview versions of the EWDK results in the build failing due to the sample using a reserved MSFT class in its INF:

[cargo-make][1] INFO - Execute Command: "infverif" "/v" "/w" "/msft" "C:\\Users\\natede\\source\\repos\\Windows-rust-driver-samples\\target/debug/echo_2.inf"
Running in Verbose
Running Windows Driver INF check
Running in MSFT driver mode

Validating echo_2.inf
ERROR(1284) in C:\Users\natede\source\repos\Windows-rust-driver-samples\target\debug\echo_2.inf, line 10: Class "Sample" is reserved for use by Microsoft.
ERROR(1285) in C:\Users\natede\source\repos\Windows-rust-driver-samples\target\debug\echo_2.inf, line 28: Cannot specify [ClassInstall32] section for Microsoft-defined class.
INF is NOT VALID

This PR updates the echo sample to use a custom "Rust_Sample" class.

[NateD-MSFT]

Ah, I just noticed that the README section discussing changes required before making a production driver calls out that the "Sample" class would need to be changed. @wmmc88 do you prefer that the sample works "out of the box" when calling cargo make, or that we require people using the sample to manually update the INF?

[wmmc88]

Hey @NateD-MSFT! The section of the readme that I believe you're referencing is actually straight from the upstream C/C++ samples repo. I would like to continue using the Microsoft Reserved Samples Class GUID, since these are also still Microsoft sample drivers.

To get around the infverif flagging, we used /msft infverif flag, similar to what the upstream C/C++ repo used. This worked without issue in NI. It looks like in the preview infverif, they've switched to using /sample with an assortment of other flags, but only for post-NI WDKs. Similar logic will need to be added into the Makefile to set WDK_BUILD_ADDITIONAL_INFVERIF_FLAGS. Same as the upstream C/C++ samples, it needs to support whatever WDK mechanisms the user is using (eWDK, installed WDK, winget WDK, etc)

[NateD-MSFT]

@wmmc88 Thanks for looking into it in more detail - I noticed the /msft flag was no longer working but wasn't aware of the /sample flag change. As for checking WDK compatibility, that's actually why I'm doing this exercise; I'll be checking the process for WDK/eWDK/package manager WDK and see what snags we hit.

I agree it makes sense to keep the sample class. I'll close this PR.