Injection of source files from dependencies into executable and shared libraries

[rikkimax]

This allows for libraries and frameworks to be able to hook into users code automatically without the user having to do anything special.

It has two use cases, although only one will work right now.

1. Having a shared library dependency that is betterC, using this feature any user directly or indirectly will receive its hook file when compiling to an executable or shared library. Allowing for the users binary image to integrate into the dependency. Such as registering a GC's root adding and subtraction functions into a memory allocator to prevent segfaults.
2. Automatically registering framework-specific concepts such as web routes or serializable structures into their respective runtime state with compile-time information being available.

The first is my primary use case right now as I cannot find another way to solve this (while remaining automatic and stable).

The second use case is missing information about all modules that have been compiled into a shared library or executable. I do want to see this implemented because it does have the potential to be a game-changer in terms of UX for some libraries and frameworks.

[rikkimax]

Currently missing is a test, dub describe for this property, changelog needs to cover the difference to sourceLibrary (@WebFreak001) and the CI Testsuite / Run (macOS-10.15, dmd-master) is failing for others, I didn't introduce that.

[WebFreak001]

• no CI tests
• add difference (e.g. example) to targetType "sourceLibrary" to changelog pls
• the name seems a little unclear, what do others think here? (a better name would e.g. be like how you named your PR or the changelog entry with something like "injectSourceFile")
• can you make the new setting a list of files / globs? I think it would be easy to adjust and the current limit to a single file seems arbitrary given the other settings that exist.
• the new setting seems to behave a lot like sourcePaths, is there anything blocking this from having platform customizations? (I think TargetInfo should have what you need to support this)

[rikkimax]

The idea is a library/framework provides a single module that acts as an entry point to perform say registration. Everything can branch off of that. For that reason, this was modeled off of mainSourceFile rather than sourceFiles.

That is why I didn't support things like globs or multiple files per package. It isn't needed where it would be used, although it wouldn't be too hard to add if people really think it's required.

I didn't add platform customizations as that seems kinda overkill. As its meant to be a single entry point that generally speaking won't care about the platform (if it does the compiler already gives you tons of information wrt. versions).

[rikkimax]

Current status:

I need opinions about these three things. If people want name change/expanded feature set (it would not be impossible to add it later, just add a plural version of it, internally it could be easily changed).

• the name seems a little unclear, what do others think here? (a better name would e.g. be like how you named your PR or the changelog entry with something like "injectSourceFile")
• can you make the new setting a list of files / globs? I think it would be easy to adjust and the current limit to a single file seems arbitrary given the other settings that exist.
• the new setting seems to behave a lot like sourcePaths, is there anything blocking this from having platform customizations? (I think TargetInfo should have what you need to support this)

no CI tests

This is going to be a lot more difficult to solve, dynamicLibrary targetType will need to be fixed first, due to the full recursiveness requiring it. See #2206.

[rikkimax]

I haven't tested conversion between sdl and json, so that'll need to be done too.