Switch default values for install from System to User directories

[AnonymerNiklasistanonym]

• Previous installs of the plugin require more than User level permission -> switch to User accessible and from Xournal supported directories while keeping everything a CMake argument for custom overrides
• Add additional support of icon install
• Instead of scanning for files once on configure update and rescan directories for new files and file changes every time the install command is ran
• Less CMake commands by extending the PreLoad.cmake file with default values (they are now also removed from the main CMakeLists.txt file)

Important

This breaks the execution of the scripts/copy_dlls.sh part but that should be fixed in combination with #51 since this pull request automatically runs the same command after each build and copies the DLLs in the same directory as the libinkpath.dll (and that directory is then copied to the install prefix / plugin name directory).
I didn't edit it to make a future merge between them less bad.
This should fix it temporarily:

IF(WIN32)
    install(CODE "execute_process(
        COMMAND bash \"${CMAKE_SOURCE_DIR}/scripts/copy_dlls.sh\"
        WORKING_DIRECTORY \"${CMAKE_BINARY_DIR}\"
    )")
ENDIF()

[WillNilges]

Thank you! Does it matter what order we merge #51 and #52 in?

[WillNilges]

Puts the files in AppData on Windows, but when I run the plugin, it says it can't find it. Possibly an issue with the Lua code?

[AnonymerNiklasistanonym]

Puts the files in AppData on Windows, but when I run the plugin, it says it can't find it. Possibly an issue with the Lua code?

Have you updated your User environmental variable Path with the new location?
The error looks to me like it finds the library but not the other .dll files in that directory that is now located in %LOCALAPPDATA\xournalpp\plugins instead of %PROGRAM_FILES%\Xournal++\share\xournalpp\plugins.

Also idk what happens if you have in both location the same plugin.
To make sure what plugin you are currently testing you probably need to remove the old directory temporarily to make sure it actually loads the right plugin.

[AnonymerNiklasistanonym]

Thank you! Does it matter what order we merge #51 and #52 in?

No it shouldn't matter, they are both independent changes that should not require any particular code edits when merging.

[WillNilges]

Sounds good, yeah I figured the path was probably incorrect. I'll update the path and try again.

[AnonymerNiklasistanonym]

(I made no changes, just rebased it onto the current master to resolve conflicts)

git rebase --onto 44ddc1829d7a995be6d27275d1af12403957769d ec328b945890e9a425a728cc5d2e33c901e139b2