Added feature to enable and disable mappings

[jayaraman-venkatesan]

feat: add soft-disable support for mappings (#1421)

Summary

• Introduces IsEnabled flag on mappings (defaults to true) that prevents a mapping from being matched without deleting it, preserving it for post-test inspection
• Adds PUT /__admin/mappings/{guid}/enable and PUT /__admin/mappings/{guid}/disable admin endpoints
• Adds EnableMappingAsync / DisableMappingAsync to IWireMockAdminApi typed client
• IsEnabled: false can be set in POST/PUT mapping body and round-trips through GET /mappings and static mapping files
• Disabled mappings appear in GET /mappings and server.Mappings — only request matching skips them

Changes

• IRespondWithAProvider — new WithIsEnabled(bool) builder method (fluent, consistent with WithProbability / WithTitle)
• RespondWithAProvider — stores _isEnabled, applies it during RespondWith()
• WireMockServer.ConvertMapping — calls WithIsEnabled(false) when mappingModel.IsEnabled == false
• MappingConverter.ToMappingModel — serializes IsEnabled as false only when disabled (null = enabled, sparse/backward-compatible)
• WireMockServer.Admin — two new regex path matchers, two route registrations, MappingEnable / MappingDisable handlers, TryParseGuidFromSecondToLastSegment helper
• MappingMatcherTests — fixed InitMappings helper and exception test mock to set IsEnabled = true (required after .Where(m => m.IsEnabled) was added); added WhenMappingIsDisabled_ShouldReturnNull test
• WireMockAdminApiTests.IsEnabled — 4 integration tests covering create-disabled, disable endpoint, enable endpoint, GET serialization

Backward compatibility

• IsEnabled defaults to true everywhere — existing mappings, JSON files, and API clients are unaffected
• IsEnabled field is omitted from JSON when true (null) and only written when false

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[StefH]

This change looks good, however can you remove this change in this PR?

I'll make a new PR which I use to fix these failing tests.

[StefH]

It's better to make the functionality the other way around.

So

public bool IsDisabled { get; set; }

In this way,it's backwards compatible.

[StefH]

Do a format-file, so that the code is alligned (extra spaces)