feat(dumper): implement time in dump path template

[nerodono]

Implements more flexible templating for storing dumps. Questions needed to be resolved in order to undraft:

• Time precision

The {time} itself has no information about precision (to hours? to minutes? to seconds?) and format (ISO? unix time?), we either need to choose format and precision, or allow customization, like strftime, but simpler: {time:dd-mm-YYYY} with some default when format is omitted.
IMO latter is better, it gives more flexibility in granularity.

• Time source

We could use last dump message time or time when writing dump to the disk. IMO latter is nice approximation, since for the rotation purposes we usually need to clean-up space, not specific time interval and using that approximation wouldn't be problematic - time of writing the dump is never less than last dump message time, so, the worst-case scenario is keeping for some time expired files in FS. Or the hell scenario is broken system clock, which is problematic in any chosen way.

[nerodono]

Holding file opened looks strange if we have dynamic parts in the template, since open time and time when happens DumpTick are different, so holding open e.g. system.network-1337.dump is not that meaningful, since we'll open new file any way. There's two possible solutions for this:

1. Divide template variables in two categories: dynamic and static. Static template variables could be pre-rendered, dynamic parts are kept as-is, this pre-rendered template with dynamic parts could be stored as a key in file registry. Can be summarized as - allow reserving whole "namespaces" of files instead of specific files.
2. Open files every time on DumpTick - simplest way

Doing things smart way (1) is even more harder if we take precision into account, for example, for file /etc/{time:YYYY} IS meaningful to hold file open, since year is not a thing that changes really fast. There's third option, hybrid of these two - if template contains any dynamic parts, open file every time on DumpTick, otherwise, hold files open, however, this options suffers from the first problem too (/etc/{time:YYYY} changes rarely), but can be worked-around by making dynamicity check smarter, like holding file open if maximum time precision is less than a hour (less = less precise, greater time steps) and relate it somehow to dump tick interval.

[nerodono]

Holding file opened looks strange if we have dynamic parts in the template, since open time and time when happens DumpTick are different, so holding open e.g. system.network-1337.dump is not that meaningful, since we'll open new file any way. There's two possible solutions for this:

1. Divide template variables in two categories: dynamic and static. Static template variables could be pre-rendered, dynamic parts are kept as-is, this pre-rendered template with dynamic parts could be stored as a key in file registry.  Can be summarized as - allow reserving whole "namespaces" of files instead of specific files.

2. Open files every time on `DumpTick` - simplest way

Doing things smart way (1) is even more harder if we take precision into account, for example, for file /etc/{time:YYYY} IS meaningful to hold file open, since year is not a thing that changes really fast. There's third option, hybrid of these two - if template contains any dynamic parts, open file every time on DumpTick, otherwise, hold files open, however, this options suffers from the first problem too (/etc/{time:YYYY} changes rarely), but can be worked-around by making dynamicity check smarter, like holding file open if maximum time precision is less than a hour (less = less precise, greater time steps) and relate it somehow to dump tick interval.

I guess we're okay as for now with whatever meaning of time used, for now it's time of opening the file or time of writing to the disk, depends on what precision of time is used, for most use-cases, where user doesn't use seconds precision, it would be time of opening the file.

[nerodono]

There's some unsafe dropped in the place, it's used only because of using libc for formatting the time. There's no small libraries implementing that feature, or there's no library that allows opt-outing most of the features so that build complexity isn't grown significantly. libc is definitely on user's build tree, so it makes no difference.

Unsafe is used to:

1. Use functions localtime_r, strftime itself
2. CString interactions

unsafe usages are isolated and tested, so I guess it's okay

[loyd]

.unwrap_or(SystemTime::UNIX_EPOCH) or more appropriate comment

[loyd]

If the active file is changed between reconfiguration and the following DumpingTick, we leave the previous one unclosed.

It seems we should replace open() also with acquire_for_write() here.

[loyd]

We can move the open logic to FileHandle and store FileHandle for a long time in every actor (instead of path and path_swap), which makes the code both clearer and less error-prone