User-hostile library names (SBU, SDU, SFU, SNU, SSU)

This core contains some built-in libraries that implement loading a sketch from various local storage mechanisms:

* **SBU**: loading from MKRNB module internal flash
* **SDU**: loading from SD card
* **SFU**: loading from SPI serial flash
* **SNU**: loading from NINA module internal flash
* **SSU**: loading from MKRGSM module internal flash

Over-the-Air updates are the most common use case for such libraries.

The issue is that since those libraries have examples, and they are installed by default, they are very prominent in the IDE examples menu but their names are quite obscure:

An option (A) could be to rename them with more descriptive names such as `LoadSketchFromSPISerialFlash` or `LoadSketchFromNINA` but this has two drawbacks:

* they would be still very prominent and confusing for a basic user, considering their niche use cases;
* the rename would break dependent libraries such as https://github.com/jandrassy/ArduinoOTA or https://github.com/arduino-libraries/ArduinoIoTCloud.

Another option (B) could be to move them to separate repositories that they don't get installed by default but this is suboptimal for code maintenance as they depend on bootloader code which is located in this repository (and it would break dependent libraries as well).

Another option (C) could be to move the examples somewhere else so that they are not displayed in the IDE menu.

Another option (D) could be to intervene on tooling, extending the `library.properties` metadata and/or changing the IDE. Examples of possible actions:

* group all these libraries under a single "Load sketch from storage" category;
* mark them as "Advanced";
* show the short description from `library.properties` so that understanding the purpose of a library is not entirely delegated to its name.

Comments?

Start by reviewing the SBU, SDU, SFU, SNU, and SSU library examples and their library.properties metadata, then trace how the IDE discovers and displays installed libraries and examples. Compare the proposed options and check the noted dependent libraries before choosing an approach. Done means the libraries are no longer confusingly prominent without breaking ArduinoOTA or ArduinoIoTCloud.

Written by the indexing model from the issue text.