Revert "cmake: make sure sha1 is computed without filters"

Commit 3315681c69 ("cmake: make sure sha1 is computed without
filters") added the `--no-filters` option to the `git hash-object`
invocation used to produce a `src/` checksum embedded in all firmware
binaries and .ldc files.

This fixed a small mismatch for the (very few) people using the
_asymmetric_ `autocrlf = input`. However it created a huge mismatch for
the numerous people using the _symetric_ `autocrlf = true`.

So revert that commit, remove `--no-filters` and replace it with a build
time warning.

`--no-filters` produces a checksum of the files as they are on the
filesystem, as opposed to how they would be input into git after
optional CRLF -> LF conversion.

When `--no-filters` was added, no one was compiling in Windows. Most
developers were not performing any conversion because there is no
`autocrlf` conversion by default on Linux.  Files were identical inside
and outside of git and life was simple.

Simple life except for at least one indomitable Linux developer who had
the _asymmetric_ `autocrlf = input` setting. Also, the SOF git repo
always had two exceptional (and generated) files with CRLF end of lines;
see issue #5917 for details (all other files have LF end of lines). So
for that "asymmetric" developer only and these two files only, `autocrlf
= input` converted these 2 files to LF before hashing and this caused a
different checksum. `--no-filters` stopped that conversion and "solved"
that mismatch.

But now Windows has entered the stage. On Windows, the default is
usually (and unfortunately) the symmetric `autocrlf = true`. It is the
default for Github's Windows runner. This symmetric default converts ALL
other files to CRLF when extracting them out of git. This causes `git
hash-object --no-filters` to produce a _different hash for all but 2
files on Windows_!

The only solution is to:

1. Drop the `--no-filters` to align everything on what is _stored in
   git_. What is stored in git is the only thing we are sure all users have
   in common.

2. Request users to use only _symmetric_ `autocrlf` settings so any
   optional input+output conversion cancels itself out.

3. Convert odd files and make sure they all have LF end of lines.

4. In the future, drop this entire git hash-object technique which is
   flawed in multiple ways and has been causing multiple issues. Much,
   much more work than this very small revert though.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>

scripts/cmake/version.cmake

@@ -114,13 +114,13 @@ if(EXISTS ${SOF_ROOT_SOURCE_DIRECTORY}/.git/)
 			OUTPUT_FILE "${SOURCE_HASH_DIR}/tracked_file_list"
 		)
 	# calculate hash of each listed files (from file version saved in file system)
-	execute_process(COMMAND git hash-object --no-filters --stdin-paths
+	execute_process(COMMAND git hash-object --stdin-paths
 			WORKING_DIRECTORY ${SOF_ROOT_SOURCE_DIRECTORY}
 			INPUT_FILE "${SOURCE_HASH_DIR}/tracked_file_list"
 			OUTPUT_FILE "${SOURCE_HASH_DIR}/tracked_file_hash_list"
 		)
 	# then calculate single hash of previously calculated hash list
-	execute_process(COMMAND git hash-object --no-filters --stdin
+	execute_process(COMMAND git hash-object --stdin
 			WORKING_DIRECTORY ${SOF_ROOT_SOURCE_DIRECTORY}
 			OUTPUT_STRIP_TRAILING_WHITESPACE
 			INPUT_FILE "${SOURCE_HASH_DIR}/tracked_file_hash_list"
@@ -128,7 +128,10 @@ if(EXISTS ${SOF_ROOT_SOURCE_DIRECTORY}/.git/)
 		)
 	string(SUBSTRING ${SOF_SRC_HASH_LONG} 0 8 SOF_SRC_HASH)
 	message(STATUS "Source content hash: ${SOF_SRC_HASH}. \
-Note: by design, source hash is broken by config changes. See #3890.")
+Notes:
+  - by design, source hash is broken by Kconfig changes. See #3890.
+  - Source hash is also broken by _asymmetric_ autocrlf=input, see
+    #5917 and reverted #5920.")
 else() # Zephyr, tarball,...
 	if(NOT "${GIT_LOG_HASH}" STREQUAL "")
 		string(SUBSTRING "${GIT_LOG_HASH}" 0 8 SOF_SRC_HASH)