Implement AdditionalExtensionDirectories[] support in the Exponential 6 extension API

This commit introduces first-class support for configurable extension repository
roots beyond the classic extension/ directory. A new INI setting
AdditionalExtensionDirectories[] in [ExtensionSettings] allows projects to
declare additional roots (most commonly extension_src/) while keeping full
backward compatibility with the existing ExtensionDirectory= value.

Why this matters for Exponential 6:

- Separates vendor/community code (extension/) from project- and
  customer-specific customizations (extension_src/ or any other root).
- Makes ownership explicit from the directory layout alone.
- Enables site extension patterns where a single package can contain a complete
  site: design, siteaccesses, grouped overrides, code, modules and autoloads.
- Lets Composer and the legacy autoload generator coexist without conflict.
- Avoids accidental overwriting of local customizations during vendor updates
  because the additional roots always win precedence over the base root.
- Provides a stable, public PHP API (eZExtension::extensionRootDirectories(),
  eZExtension::extensionPath(), eZExtension::expandedPathList(),
  eZExtension::extensionName() and the filterExtensionRootDirectories() hook)
  that every kernel and extension consumer can rely on.
- Keeps cp -r between roots the only operation needed to move, fork or shadow
  an extension; no manifest edits or composer dump-autoload runs are required.

Implementation highlights:

- lib/ezutils/classes/ezextension.php now exposes the public API and resolves
  extension names case-insensitively across all configured roots with a clear
  later-root-wins precedence rule. All internal caches are keyed on the root
  list so INI changes invalidate them automatically.
- kernel/private/classes/ezautoloadgenerator.php and
  bin/php/ezpgenerateautoloads.php were updated to scan every configured root
  for classes, kernel overrides and test classes, producing
  var/autoload/ezp_extension.php, var/autoload/ezp_override.php and
  var/autoload/ezp_tests.php from the union of all roots.
- ezpExtension (kernel/private/classes/ezpextension.php) uses the new helper
  to load extension.xml, ezinfo.php and loading order data from the correct root.
- More than thirty kernel, library, script and test consumers were converted
  away from hard-coded extension/ paths and eZExtension::baseDirectory()
  concatenations toward eZExtension::extensionPath() and
  eZExtension::expandedPathList(). The affected areas are design resolution,
  module repositories, siteaccess discovery, settings editing, datatype handling,
  workflow/notification/shop handler discovery, RSS imports, SOAP, package
  install/uninstall/create, translation roots, icon repositories, content
  upload/edit/tree handlers, collaboration handlers, template compilation,
  system upgrade checksum/schema handling, cron job siteaccess detection and the
  test runner.
- tests/tests/kernel/classes/eZExtensionAdditionalDirectoriesTest.php was
  added to cover root discovery, precedence, case handling, fallback and
  active-extension resolution.
- doc/bc/6.0/AdditionalExtensionDirectories.md was rewritten from the RFC
  draft into a stable post-implementation reference documenting the API, the
  INI settings, precedence, migration path and updated consumers.

Backward compatibility:

- ExtensionDirectory=extension remains the default and is unchanged when
  AdditionalExtensionDirectories[] is absent or commented out.
- Existing extension/ packages are neither moved nor renamed.
- Composer scripts keep invoking bin/php/ezpgenerateautoloads.php; the
  generator simply scans more roots when configured.
- No composer dump-autoload is required when adding, moving or shadowing a
  package between roots.

Updated: Updated kernel/content/view.php sevenxValkeyCacheBlock section to respect no cache usage without the use of new path. Bugfix.

Updated: Updated README.md documentation to more clearly explain and reword composer requirements warnings and instructions. Doc.

Updated: Updated composer.json to provide the latest release of the powercontent extension. Enhancement

Add syndication and database source editor extensions.

This commit adds two production extensions to composer.json:

- se7enxweb/syndication ~1.2.0 — enables SOAP-based content syndication
  between separate Exponential installations, supporting centralized user
  registration, content syncing, feed sources, import/export filters and
  cronjob-driven replication for multi-site deployments.

- se7enxweb/sevenx_dse ~1.0.0 — embeds AdminNeo as a permission-gated
  database source editor within the admin UI, providing raw SQL execution,
  table browsing, import/export and multi-driver support (MySQL, PostgreSQL,
  SQLite, MS SQL, Oracle) without leaving Exponential.

Both packages are installed through the existing se7enxweb/exponential-legacy-installer
and are managed alongside the other eZ Publish Legacy extensions in composer.json.

Add ICONS.md documentation for the mainlined icon theme support.

Documents the bciconextensions and bciconextensions_share_icons
integration into Exponential 6.0.15-alpha so developers can:

- Place icon themes in extension/<name>/icons/<theme>/ instead of patching
  the kernel or copying files into share/icons.
- Configure theme fallback chains: current theme → AdditionalThemeList[]
  themes → StandardTheme.
- Configure repository fallback chains: extension icon directories are
  searched before the default share/icons repository.
- Add custom class, MIME, class group, action, and flag icons through
  icon.ini settings and theme icon.ini maps.
- Remove the legacy bciconextensions and bciconextensions_share_icons
  extensions from ActiveExtensions[] after upgrading.
- Test the icon operators in 2 minutes using the shipped job icon and a
  command-line template snippet.

The documentation also covers web server requirements for serving static
icons from extension directories and includes a complete INI reference.

Mainline bciconextensions icon theme support and ship a default job icon.

This integrates the legacy bciconextensions and bciconextensions_share_icons
functionality into the Exponential kernel so sites no longer need a kernel
override or special autoload configuration to use extension-resident icon
themes.

Features and developer benefits:

* Extension-resident icon themes — place icon sets in
  extension/<name>/icons/<theme>/ instead of copying files into share/icons or
  patching the kernel. This keeps custom icon assets with the extension that
  ships them and simplifies updates.

* Theme fallback chain — the icon engine searches the current theme first,
  then any AdditionalThemeList[] themes, and finally the StandardTheme. This
  makes it safe to layer admin or custom themes on top of a base theme.

* Repository fallback chain — for each theme, extension icon directories are
  searched before the default share/icons repository. Sites can override a
  stock icon by shipping a same-named icon in an extension without touching
  core files.

* Default icon fallback — when an icon cannot be resolved, the theme or
  override Default icon is used instead of generating a broken <img> tag,
  which keeps the admin interface and front-end templates visually stable.

* Static file serving — icons under extension/*/icons/ are ordinary static
  files served directly by the web server, so no extra PHP work is done for
  each image request.

* Default job icon shipped — the job.png icon from bciconextensions_share_icons
  is now part of the crystal-admin theme and mapped to the job class by
  default.

Files changed:

* kernel/common/ezwordtoimageoperator.php — extension/theme search, fallback
  handling, and IconExtensions[] support.
* settings/icon.ini — added StandardTheme, AdditionalThemeList[], and
  IconExtensions[] defaults.
* share/icons/crystal-admin/icon.ini — added ClassMap[job]=apps/job.png.
* share/icons/crystal-admin/16x16_indexed/apps/job.png and
  share/icons/crystal-admin/32x32/apps/job.png — new default icon assets.