Implement on-demand source processing

[Vladyslav-Kuksiuk]

This PR changes the source-processing flow from eager preprocessing to on-demand source resolution.

Changed source-processing flow

Previous flow:

1. All source code files were scanned up front.
2. Each source file was split into fragments, cleaned from fragment marker comments, normalized, and written into build/fragments.
3. Target documents were scanned and embedded snippets were read from those prepared fragment files.

New flow:

1. Target documents are scanned first.
2. Source files are processed only when they are referenced by an <embed-code> instruction.
3. Named fragments are resolved directly from source and cached in memory per source file.

Additional changes

• Removed code-includes / code-excludes configuration, as it doesn't make sense anymore.
• Removed fragments-path configuration.
• Improved check mode outputs:
  
  

Issues

• Closes Make the build directory configurable #29, as we don't have fragments in the build directory anymore.
• Closes Clarify the "Providing fragments directly" section in the EMBEDDING.md documentaiton #28, as we don't have this feature anymore.
• Resolves Embedding and checking are painfully slow #27. On an M3 Max, the average processing time for the Spine Validation docs was reduced from 3.5 seconds to 0.07 seconds.
  It is highly likely that the time mentioned in the issue is the result of the fragments directory was included in the code-path, causing each run to process and store previous fragments, which increases the number of files to process in geometric progression.

[dmytro-kashcheiev]

@Vladyslav-Kuksiuk LGTM

[alexander-yevsyukov]

@Vladyslav-Kuksiuk,

Improved check mode outputs:

All the errors come in the plain text flow. Can we, please, have each error on a separate line prefixed with -?

Please file an issue for this.

@dmytro-kashcheiev, FYI.

[alexander-yevsyukov]

@Vladyslav-Kuksiuk,

Files outdated:

Please change this text to "Files to update:".