[feature] Allow showing variables devices inherit from related objects in REST API

⚠️ Not suited for beginner contributors.

A DESIGN DECISION AND MORE DISCUSSION ARE NEEDED ON THIS SUBJECT BEFORE MOVING FORWARD.
Please do not send a PR without having discussed your solution with the core devs first (for discussions, join our dev matrix chat).

The admin preloads and presents configuration variables so they can be understood and edited where appropriate. The REST API does not provide an equivalent, complete mechanism.

This work must cover every OpenWISP Controller model that defines or resolves configuration variables, rather than only the device API:

• Device and Config: device-specific variables and the resolved effective context.
• Template: default values and VPN-server variables.
• DeviceGroup: group variables.
• OrganizationConfigSettings: organization variables.
• Vpn: VPN-server context.

The API must distinguish stored, user-editable variables from computed system-defined variables. Computed values should be read-only, and the design must account for sensitive values such as certificate material, private keys, and VPN secrets.

I think we can add either one or multiple properties showing these variables separately from the device configuration context. To avoid increasing normal list and detail response costs, this should be opt-in with a GET parameter. The design must define the response shape, permission and organization checks, query optimization, and which sensitive values are redacted or excluded.

The current user documentation in docs/user/variables.rst describes the variable sources and states that system-defined variables are displayed in the admin UI. Once an API contract is agreed, update this page and docs/user/rest-api.rst to document the supported models, opt-in parameter, response fields, and sensitive-data behavior.

Start by reviewing docs/user/variables.rst and docs/user/rest-api.rst, then discuss the API contract with the core developers before changing anything. The work is done when the supported models, opt-in parameter, response fields, permissions, optimization, and sensitive-data behavior are agreed and documented.