[feature:gsoc26] Introduce DeviceCertificate relational model for standalone certificates

Is your feature request related to a problem? Please describe.
Currently, there is no robust relational way to track which standalone X.509 certificates belong to which device configurations, or which template originally generated them. Relying on string-matching the common_name to bind certificates to devices is fragile and prone to edge-case collisions, especially in large-scale deployments.

Describe the solution you'd like
I will introduce a DeviceCertificate intermediate Many-To-Many (M2M) model to act as a strict relational bridge. This directly mirrors OpenWISP's proven VpnClient architecture, enforcing strong Foreign Key constraints between the device configuration, the template, and the generated physical certificate.

Create a DeviceCertificate model with the following fields:

• config: ForeignKey to the Config model, the device's configuration.
• template: ForeignKey to the Template model, the template that triggered creation.
• cert: OneToOneField to the django_x509.Cert model, the actual generated X.509 certificate.
• auto_cert: BooleanField to track whether the certificate is auto-managed by the system.
• Enforce unique_together = ('config', 'template') at the database level to ensure a single device configuration cannot generate multiple conflicting certificates from the same template.

Relationship with lifecycle issue

This issue tracks the relational model described in the proposal. The lifecycle behavior that uses this model, including assignment, generation, revocation, renewal, and config status updates, is tracked in #1358.

Measurable outcome: 3
Implementation point: 2, 3