Random binary patter triggers variable replacement in zip payload

**Version**
2.8.0

**Problem description**
When I add a zip file as payload to a HTTP message, Citrus tries to replace variables in the binary payload. If the pattern `\$\{[a-zAZ_0-9]+\}` is found in the binary payload or in file names inside the zip, the test fails. The replacement of variables in a payload, that should be send as a binary stream is a intended behavior. This allows us, to pass plain text to Citrus which is enriched with variables and transmitted as binaries. It's just unfortunate that random binary pattern break this.

```
11:36:55.317 [main] ERROR com.consol.citrus.report.LoggingReporter - TEST FAILED TodoListIT.testGet Nested exception is:
com.consol.citrus.exceptions.TestCaseFailedException: Unknown variable 'NoVariable'
```

**Additional information**
```java
public class ZipWithVariable extends TestNGCitrusTestRunner {

@Autowired
private HttpClient httpClient;

@Autowired
private HttpServer httpServer;

@Test
@CitrusTest
public void testGet() {
http( action -> action.client(httpClient)
.send()
.post()
.messageType(MessageType.BINARY)
.contentType("application/zip")
.payload(new ClassPathResource("foo.zip")));

http(action -> action.server(httpServer)
.receive()
.post()
.messageType(MessageType.BINARY));

http(action -> action.server(httpServer)
.respond());

http( action -> action.client(httpClient)
.receive());
}
}
```
Sample [foo.zip](https://github.com/citrusframework/citrus/files/2807314/foo.zip).

A possible solution could be to extend the `ZipMessage` with an `importFromResource` method or something like that so that a given zip file is imported correctly.

BR,
Sven

Start with ZipMessage and the HTTP send action using MessageType.BINARY, then trace how the ClassPathResource payload is imported and variables are replaced. The issue's proposed importFromResource method is a possible entry point, but the desired behavior must preserve variable substitution for intended binary messages while avoiding accidental replacement in ZIP content and filenames. Done means the supplied foo.zip payload sends successfully without an unknown-variable failure.

Written by the indexing model from the issue text.