Create new device for tests that deploy configs

[damonbarry]

The new end-to-end tests have become increasingly flaky as more tests (and more complicated tests) have been added. This is largely because most of the tests share the same edge device identity, which leads to at least two problems:

• As more configurations are deployed, edge hub works increasingly harder to route traffic, often to devices/modules from previous tests that have already been removed. Tests that run near the end of the suite end up failing randomly, simply because we aren't waiting long enough for edge hub to work as designed under rapid configuration churn (nor can we afford to wait; the tests need to run reasonably fast).
• The currently-running test has no way to know when edge hub has changed it's routes to match the current deployment, as opposed to the previous deployment from the previous test. This means that when a test's modules start sending messages, those first messages might be delivered to the wrong destination or not delivered at all. Many tests carefully count received messages so they're sensitive to this problem.

With this change, we create a new edge device identity for any test/fixture that deploys its own configuration. This allows edge hub to start up fresh each time, and tests can more readily verify the exact scenario they're testing. And we still get the speed benefit of only installing iotedged once per run (as opposed to the old end-to-end framework, which installs everything from scratch for every test--reliable but slow).

Included changes:

• Add a DeviceId class that can generate unique IDs from a common base. The base ID is used as the prefix for all logs in a single test run.
• Remove DeviceId property from the Context class. Early on, it was nice to be able to pass in a device ID instead of having the tests generate one, but it's not really that useful anymore, and the new approach is much simpler.
• Promote the DeviceId property on EdgeRuntime to public.
• In code locations that formerly referred to Context.Current.DeviceId: use DeviceId.Generate() to get a new device ID if needed, otherwise use EdgeRuntime.DeviceId to get the parent edge device's ID.
• Remove the IdentityLimits class. The DeviceId class now centralizes and encapsulates the creation of device IDs so callers don't have to remember to check length limits after creating their own IDs.
• Push SAS- and X509-specific code from ManualProvisioningFixture into the appropriate derived classes. ManualProvisioningFixture could probably go away but would require more careful thought so holding off on that.
• In SasManualProvisioningFixture, change the [OneTimeSetUp] method to [SetUp] so that each test under this fixture gets a new edge device identity. The exception to this rule is tests under the derived CustomCertificatesFixture (TransparentGateway tests), which only gets one shared device by overriding [SetUp] with an empty method, and instead calling the parent logic from [OneTimeSetUp].
• In X509ManualProvisioningFixture, remove some unused variables.
• In the ValidateMetrics test we were deploying a vanilla agent image first so that the agent would get updated when we deploy it with special config later (see Improve ValidateMetrics test on Windows #2583). Now that we configure iotedged with a fresh device before starting the test, it will automatically start out with the vanilla agent so I removed the workaround code from the test.
• In the Module test class, several tests use the temp sensor module so the TempSensorModule helper class was created to hand out unique module names to avoid edge hub routing conflicts. But now that we restart iotedged with a fresh device ID for each test, we don't need the helper class anymore. I removed it.
• Refactor some test code to follow style guidelines, e.g., don't explicitly call default base constructor, don't explicitly decorate class members with private, etc.

[dylanbronson]

LGTM - Linux went all green with this PR. Windows still has issues, but unrelated to this PR it seems