[addons] fix binary addon lib name for iOS

[AlwinEsch]

Description

By 609d390 was this forget and overseen from me by review, this fix the name for iOS to have equal with the other.

Motivation and Context

How Has This Been Tested?

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)
• 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

[fuzzard]

Ive got a potential issue with this library section. But not entirely sure im across how the library_xxx is used, so disregard if im incorrect in my assumptions.

In the kodi system addons (audioencoder.kodi.builtin., screensaver.xbmc.builtin.) the library name is set based off @CORE_SYSTEM_NAME@. For platforms like rbpi, the code in CBinaryAddonType::GetPlatformLibraryName will never actually match library_rbpi, and will fall through to library_linux. This is the same for why the ios change is needed after your cpluff rework, as core_system_name is darwin_embedded, and core_platform_name is ios.

My proposal would be to change the addons to not use @Core_system_name@, but to actually use @core_platform_name@ (or core_platform_name_lc). This would then mean the match against library_rbpi would/could succeed, and also, you can then leave the ios match for library_ios.

For the linux gbm/x11 matches that you would get, you can just leave the existing fall through to match against library_linux.

This same situation was already in place prior to your cpluff rework, but for some reason it didnt fault during the addon startup, and im guessing that it was mostly by pure luck, not by design.

What im not familiar with is how 3rd party addons interact/use this library_xxx, or if they do at all. If anyone can enlighten me, that would be greatly appreciated just for my own curiosity/info

[AlwinEsch]

From my side it might make maybe sense to remove it completely and use only library=.
And leave the check by <platform>@PLATFORM@</platform>.

Note @PLATFORM@ is on external addons and equal to @CORE_SYSTEM_NAME@, which is not correct enough and maybe improve and use the @PLATFORM_TAG@ (https://github.com/xbmc/xbmc/blob/master/cmake/scripts/common/PrepareEnv.cmake#L39) on cmake.