Cisco IOS Messages parsed with Syslog Input

AFAIK the following configurations are available - the first line is the configuration string on Ciscos IOS the second the logline that is produced with that kind of configuration:

## Cisco IOS
service timestamps log uptime
<189>82: 00:20:10: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime
<189>83: *Feb 28 00:20:10: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime msec
<189>88: *Feb 28 00:20:10.663: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime year
<189>86: *Feb 28 2010 00:20:10: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime show-timezone
<189>92: *Feb 28 00:20:10 UTC: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime msec year
<189>90: *Feb 28 2010 00:20:10.663: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime msec show-timezone
<189>93: *Feb 28 00:20:10.663 UTC: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime year show-timezone
<189>94: *Feb 28 2010 00:20:10 UTC: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

service timestamps log datetime msec year show-timezone
<189>91: *Feb 28 2010 00:20:10.663 UTC: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.200.1)

The second number after the Syslog Priority is a sequence number that enables you get the correct order of events even without milliseconds.

I'm not sure if we should just document what is working or if we need to adjust the Syslog Input to fit as many options as possible.

## Context
nearly all users with Cisco hardware have other settings but think that they send valid syslog. While valid RFC3164 would be:

<###>Mmm dd hh:mm:ss hostname tag msg

The Cisco delivered messages are close to that but not really what we think will be delivered. The current `magic` that parses the Syslog Input is not always correct so the result for the user looks unpredictable.

## Your Environment
* Graylog Version: 2.4