No error displayed when patch matches existing bytes

[A1mDev]

Description:
Currently, the extension does not display any warning or error if the patch bytes are identical to the bytes already present in the binary.
This can mislead users into thinking a patch was applied when in fact nothing changed.

Additionally, this situation can occur if another plugin has already applied a similar patch. In such cases:

• The patch may conflict with the existing one.

• No errors or warnings are displayed.

• The patch might not be removed correctly during unpatching.

Steps to reproduce:

1. Apply a patch through another plugin or extension that modifies the same memory bytes.

2. Load this extension and apply a patch with the same bytes.

3. Observe that no error or warning is logged, and the patch may not behave as expected.

Expected behavior:

• The extension should detect that the patch has no effect or conflicts with existing patches and log a warning or informational message.

• Conflicting patches should be handled safely, and unpatching should restore memory correctly.

Additional context / suggestion:

• Consider adding a check in Enable() or during parsing to compare vecPatch with the current memory bytes.

• Log clear messages to help users troubleshoot patch conflicts.

[nosoop]

Conflicting patches should be handled safely, and unpatching should restore memory correctly.

My longstanding view on this was on #2 — SourceMod ships with address write primitives and the extension intentionally allows patches that preserves all bytes so they can be overlaid in plugin space, so a patch stack of "undo" operations doesn't quite make sense when plugins may have altered those values (e.g. a plugin unload restoring bytes for a different plugin that was long since unloaded).

I've never considered it a priority to implement, but I am open to accepting a PR that reports an error if attempting to enable a patch in a range that an existing patch is enabled for. Would probably need #11 addressed at the same time.