[feature:gsoc26] Integrate Certificate Templates into REST API

Is your feature request related to a problem? Please describe.
With the AbstractTemplate model extended to support type="cert", the new ca and blueprint_cert relational fields must be exposed via the REST API. Without this, programmatic management of PKI templates is impossible, blocking third-party integrations and automation scripts.

Describe the solution you'd like
I will update the API serializers and existing endpoints to natively support the new template type:

1. Template Serializer: update the API serializers to conditionally expose the ca and blueprint_cert fields. The validation logic must enforce that ca is strictly required when type="cert", but ignored for other template types.

2. Blueprint Validation: ensure the serializer's validation prevents a certificate assigned to a DeviceCertificate from being selected as a blueprint_cert.

3. Device Serializer: ensure the Device API serializer correctly handles assignments, transparently creating or destroying DeviceCertificate relationships when templates are patched.

4. Organization Scoping: ensure that existing OpenWISP multi-tenant RBAC and organization scoping are strictly applied to both the ca and blueprint_cert fields during API creation and updates.

Requirements from the GSoC proposal

• Expose the new Certificate template type within the current REST API template endpoints.
• Do not introduce new API endpoints unless the plan changes during implementation.
• Reuse OpenWISP's existing role-based access control.

Tests from the GSoC proposal

• Creating a certificate template via the REST API.
• Template serializer includes ca and blueprint_cert fields.
• Validation rejects certificate templates without CA.
• Existing RBAC and organization scoping apply.
• Assigning or removing certificate templates through the API triggers the same lifecycle behavior tracked in #1358.

Measurable outcomes: 7
Implementation points: 6, 7