Implement psps without relying on aux_source_directory

[matzipan]

Is your feature request related to a problem? Please describe.
The CMake documentation presents the following caveat for aux_source_directory:

It is tempting to use this command to avoid writing the list of source files for a library or executable target. While this seems to work, there is no way for CMake to generate a build system that knows when a new source file has been added.

Describe the solution you'd like
The targets should have a list of files that go into making the specific psps.

Requester Info
Andrei Zisu of Planetary Transportation Systems (Berlin, Germany).

[jphickey]

I think this would be a good change, and it would make PSP's more modular and therefore more consistent with apps and the way everything else works. With this the change to do an out-of-tree PSP is also more straightforward and logical.

[jphickey]

This is actually necessary in order to merge nasa/osal#312, so I'll do this.

[skliper]

Would this along with the related source selection via cmake options make the psp module concept redundant?
Or does the concept of adding modules still give us something unique?

[jphickey]

I actually liked the idea of going full-modular with PSP's. That is, the "psp name" simply translates to a list of modular components to build for platform support. I briefly experimented with this and I think it could work nicely.

That is, in my experiment, the PSP was defined like this:

set(pc-linux_MODULELIST
    pc-linux-startup
    virtual-1hz
    no-exceptions
    no-ssr
    no-watchdog
    port_stub
    ram_stub
    eeprom_stub
)

This is convenient in that any/all of those modules can exist out-of-tree, using the currently existing module/app search logic.

[skliper]

I definitely like the single mechanism for defining the modules included the PSP as you show above, and using the existing search logic! Seems like a great simplification.