Added an option to add arbitrary headers to the client requests

The headers are key/value pairs defined in the settings under the `request.headers` namespace.

Also changed test infrastructure's so it'd be possible to define the additional settings for transport clients.
> yeah...been there...done that... :) even if you disable requests validation you'll run into problems when serializing the request (writeTo method). Can't you use a fake request so that validation and serialization are not a problem, and then call execute and check that requests get set? Not sure it is really needed to check every single request at this point?

actually, without validation reflection approach would work (the mock transport shortcuts execution before requests are serialized). But enabling an option to disable validation, just for testing, feels wrong (there's no scenario anyone should be able to do this outside of testing)

> I'd love to see a unit test around this though, I don't think this necessarily requires a running node, you could just create your own mock transport service that checks that each request contains the headers (you don't have to send the request for real). You could make it work without even requiring a transport client but by testing InternalTransportClient as I did here:

fair enough... I'll see if I can change the test to not depend on the cluster at all

> Also, I'm a bit hesitant on the changes to the test infrastructure that are needed for this single test. I'd rather prefer to have a manually created transport client here with the settings, or not even require a complete transport client if you go for the unit test.

This is actually a good extension for the testing infra. it should be possible to customize the configuration of transport clients (right now it's not possible). But I agree that if this PR won't depend on the cluster infra, it's better to create a separate PR for it