[Cmake][modules] Cleanup and utilisation of new function to link libraries

[fuzzard]

Description

Introduce a new function core_target_link_libraries to automatically link to a given target the optional/required dependencies when they exist.
Also start a general cleanup/consistency across modules with recent improvements to the model

Motivation and context

We have our list of optional/required deps, so instead of having each find module to manually add/track using a custom property (INTERNAL_DEPS_PROP), we just set our target names to a standard of ${APP_NAME_LC}::${CMAKE_FIND_PACKAGE_NAME} and then use a macro to iterate over the optional and required dependency lists to do a target_link_libraries call from a given target to the dependencies.
Also some general consistency, and minor fixups. This is only about half. i'll do the rest at another point in time, as well as brining more old style modules up to this style of target use

The end goal will be to remove the INTERNAL_DEPS_PROP usage, as this allows more targetted usage.

Once all modules are using targets, we can remove the macro usage around DEP_DEFINES, DEPLIBS and SYSTEM_INCLUDES variables

How has this been tested?

Jenkins and some manual inspection of cache and build files to make sure definitions and libs are being used/linked

What is the effect on users?

N/A

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[garbear]

I've started reviewing this. I pulled it into my RP test builds. I appreciate that you alphabetized the dependencies.

[fuzzard]

Any objections to merging this? Got something else in the pipeline dependant on it.

[garbear]

No objections on my end.

[mackal]

This is breaking Avahi support here

  The link interface of target "kodi::Avahi" contains:

    Avahi::AvahiCommon

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  cmake/scripts/common/Macros.cmake:404 (find_package)
  cmake/scripts/common/Macros.cmake:453 (find_package_with_ver)
  CMakeLists.txt:260 (core_optional_dep)

I do see -- Found Avahi: /usr/lib64/libavahi-client.so (found version "0.8") in the log, so I assume just at typo somewhere.

Turning off the zeroconf use flag (disable avahi support) on gentoo compiles just fine.