removed trimspace in write method

[Bobby-88]

This fixes #37
Trimspace causes number of bytes wirtten to be not equal to number of bytes requested to write - this causes an error in multiwriter
Happy to help with other tests if needed

[CLAassistant]

All committers have signed the CLA.

[Bobby-88]

@mariussturm i've just noticed that somehow this PR also will update README.md - this was not my intent, please ignore commit #8a6a140bfa5cdfce8768648e8a7ddf3c13b04be9

[mariussturm]

@Bobby-88 under what conditions exactly do you have problems with the trimspace?
Messages starting with whitespaces look odd in the Graylog web interface so we trim them usually.

[Bobby-88]

@Bobby-88 under what conditions exactly do you have problems with the trimspace?
Messages starting with whitespaces look odd in the Graylog web interface so we trim them usually.

Sorry for delay.
Here is a piece of code which gives me warnings if i don't trim whitespaces

gelfWriter, err := gelf.NewWriter("192.168.20.6:12201")
	if err != nil {
		log.Error().Msgf("gelf.NewWriter: %s", err)
	}
log.Logger = zerolog.New(os.Stdout).With().Timestamp().Logger().Output(zerolog.MultiLevelWriter(zerolog.ConsoleWriter{Out: os.Stderr, NoColor: true}, gelfWriter))

[thaod]

@Bobby-88 under what conditions exactly do you have problems with the trimspace?
Messages starting with whitespaces look odd in the Graylog web interface so we trim them usually.

@mariussturm I think the writer should respect provided data to send it as is, even with leading white spaces. Problem with odd UI should be resolved in the Graylog web interface logic, not log writer.

[mjjs]

This seems sensible. Especially if the only reason to trim it is to fix the UI. As thaod pointed out, it's more logical to do this in the UI code.