Replace System.Web with System.Net.WebUtility in data migration

[hahn-kev]

This allows us to remove our dependency on System.Web.HttpUtility which is designed for use on the server per https://learn.microsoft.com/en-us/dotnet/api/system.web.httputility?view=net-10.0#remarks

for DataMigration7000040Tests.cs I removed the unused copy-pasted helpers that still referenced System.Web and were never called by the test.

---

This change is 

[github-actions]

LCM Tests

    16 files  ±0      16 suites  ±0   3m 4s ⏱️ +2s
 2 863 tests ±0   2 843 ✅ ±0   20 💤 ±0  0 ❌ ±0 
11 400 runs  ±0  11 232 ✅ ±0  168 💤 ±0  0 ❌ ±0 

Results for commit 02d34b1. ± Comparison against base commit 840564b.

[imnasnainaec]

@imnasnainaec reviewed 5 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on hahn-kev).

---

a discussion (no related file):
One observation by Devin:

src/SIL.LCModel/DomainServices/DataMigration/DataMigration7000037.cs:133

URL encoding output will have different hex casing in migrated data

The switch from HttpUtility.UrlEncode to WebUtility.UrlEncode (DataMigration7000037.cs:133) produces uppercase hex digits (%3D, %3A, %26) instead of lowercase (%3d, %3a, %26). For example, app=flex&tool=interlinearEdit would previously encode as app%3dflex%26tool%3dinterlinearEdit but now encodes as app%3Dflex%26tool%3DinterlinearEdit. Both are valid per RFC 3986 and decode identically, but any database that still needs this migration applied will get cosmetically different stored data than it would have under the old code. Since this is a one-time migration (version 7000036→7000037) and most databases have long since been migrated, the practical impact is negligible.