INT-832: Add File Relative Path to Message Headers

JIRA: https://jira.spring.io/browse/INT-832

When we scan directory recursively for files (e.g. `WatchServiceDirectoryScanner`), it can be useful to get access to the relative path from the `Message`, e.g. on the `FileWritingMessageHandler` side to restore the original structure

* Add a `FileHeaders.FILENAME` into the outbound `Message` from the `FileReadingMessageSource`
* The result of that header is like a removal of leading `this.directory.getAbsolutePath()` in the target `File.getAbsolutePath()`.
In case of not recursion we get just only regular file name.

* Introduce `FileHeaders.RELATIVE_PATH`
* Populated `FileHeaders.RELATIVE_PATH`, `FileHeaders.FILENAME`, `FileHeaders.ORIGINAL_FILE` in the `FileReadingMessageSource`
* File `FileTailingMessageProducerSupport` to populate `FileHeaders` properly
* Introduce ctor for the `LastModifiedFileListFilter` for better Java configuration experience
* Add docs for changes

Doc Polishing

src/reference/asciidoc/file.adoc

@@ -24,7 +24,8 @@ This is an implementation of `MessageSource` that creates messages from a file s
     p:directory="${input.directory}"/>
 ----
 
-To prevent creating messages for certain files, you may supply a `FileListFilter`. By default the following 2 filters are used:
+To prevent creating messages for certain files, you may supply a `FileListFilter`.
+By default the following 2 filters are used:
 
 * `IgnoreHiddenFileListFilter`
 * `AcceptOnceFileListFilter`
@@ -105,6 +106,19 @@ to, say, network glitches.
 </bean>
 ----
 
+*Message Headers*
+
+Starting with _version 5.0_ the `FileReadingMessageSource`, in addition to the `payload` as a polled `File`, populates these headers to the outbound `Message`:
+
+- `FileHeaders.FILENAME` - the `File.getName()` of the file to send.
+Can be used for subsequent rename or copy logic;
+- `FileHeaders.ORIGINAL_FILE` - the `File` object itself.
+Typically this header is populated automatically by Framework components, like <<file-splitter>> or <<file-transforming>>, when we lose the original `File` object.
+But for consistency and convenience with any other custom use-cases this header can be useful to get access to the original file;
+- `FileHeaders.RELATIVE_PATH` - a new header introduced to represent the part of file path relative to the root directory for the scan.
+This header can be useful when the requirement is to restore a source directory hierarchy in the other places.
+For this purpose the `DefaultFileNameGenerator` (<<file-writing-file-names>>) can be configured to use this header.
+
 *Directory scanning and polling*
 
 The `FileReadingMessageSource` doesn't produce messages for files from the directory immediately.
@@ -399,6 +413,14 @@ This sequence of events might occur, for example, when a file is rotated.
 
 NOTE: Not all platforms supporting a `tail` command provide these status messages.
 
+Messages emitted from these endpoints have the following headers:
+
+- `FileHeaders.ORIGINAL_FILE` - the `File` object
+- `FileHeaders.FILENAME` - the file name (`File.getName()`)
+
+NOTE: In versions prior to _5.0_, the `FileHeaders.FILENAME` header contained a string representation of the file's absolute path.
+You can now obtain that by calling `getAbsolutePath()` on the original file header.
+
 Example configurations:
 
 [source,xml]

src/reference/asciidoc/whats-new.adoc

@@ -37,6 +37,11 @@ See <<gateway-error-handling>> for more information.
 Some inconsistencies with rendering IMAP mail content have been resolved.
 See <<imap-format-important, the note in the Mail-Receiving Channel Adapter Section>> for more information.
 
+==== File Changes
+
+The new `FileHeaders.RELATIVE_PATH` Message header has been introduced to prepresent relative path in the `FileReadingMessageSource`.
+See <<file-reading>> for more information.
+
 ==== (S)FTP Changes
 
 The inbound channel adapters now have a property `max-fetch-size` which is used to limit the number of files fetched during a poll when there are no files currently in the local directory.