feat(ui,legal,openapi,security): add internal policy pages & configurable legal URLs

[Ludy87]

Description of Changes

What was changed

• Added internal policy pages and routes in HomeWebController for:
  • /impressum, /privacyPolicy, /termsAndConditions, /cookiePolicy, /accessibilityStatement with 404 when not enabled/misconfigured.
• Introduced sample Thymeleaf templates for all legal pages (impressum.html, privacyPolicy.html, termsAndConditions.html, cookiePolicy.html, accessibilityStatement.html) to support self-hosted customization.
• Extended settings.yml.template:
  • New legal section defaults and clear guidance for internal vs external URLs.
  • Added legal.apiContact (company, email, website) for Pro/Enterprise branding in API docs.
• Updated ApplicationProperties:
  • Added ApiContact model under Legal for structured contact metadata.
• Refactored OpenApiConfig:
  • Pulls app version from ApplicationProperties.automaticallyGenerated.appVersion with sane fallback.
  • Uses defaults for title/description/license/ToS and, if runningProOrHigher, overrides title/description/ToS and contact from configuration (legal.apiContact).
  • Keeps API key security scheme behavior intact.
• Footer behavior change:
  • Legal links now render only when the value is not '/', enabling an explicit “disabled” state.
• Security / auth adjustments:
  • Proprietary SecurityConfiguration: whitelisted internal policy routes for unauthenticated access when configured internally.
  • UserAuthenticationFilter: added policy routes to the skip list.
  • AccountWebController: redirects away from /login if login is disabled.
• Minor improvements:
  • licenses handler now uses try-with-resources.
• Test scaffolding:
  • Added policy routes to testing/webpage_urls.txt and webpage_urls_full.txt.

Why the change was made

• Provide built-in, customizable legal pages for deployments needing compliant disclosures (e.g., Impressum, privacy, cookies, accessibility, terms).
• Make OpenAPI metadata brandable in Pro/Enterprise environments and reflect correct contact/ToS.
• Simplify configuration with explicit enable/disable semantics and safer defaults.
• Ensure policy pages are reachable without authentication while keeping other areas protected.

---

Checklist

General

• [x] I have read the Contribution Guidelines
• [x] I have read the Stirling-PDF Developer Guide (if applicable)
• [ ] I have read the How to add new languages to Stirling-PDF (if applicable)
• [x] I have performed a self-review of my own code
• [x] My changes generate no new warnings

Documentation

• [ ] I have updated relevant docs on Stirling-PDF's doc repo (if functionality has heavily changed)
• [ ] I have read the section Add New Translation Tags (for new translation tags only)

UI Changes (if applicable)

• [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)

Testing (if applicable)

• [ ] I have tested my changes locally. Refer to the Testing Guide for more details.

[Frooodle]

/deploypr

[Frooodle]

Some issues with this We would want it to use our policies by default, and allow them to turn it off if they want

We should add that removing privacy policies whilst also having metrics enabled is against GDPR and at their own discretion (allow them but ensure they know its their choice) If analytics is enabled, This may violate privacy laws depending on your jurisdiction. Proceed only if you understand the risks.