This is fairly low priority. I was experimenting with pyparam / talloc and noticed the following behavior:

```
>>> talloc.report_full(a)
full talloc report on 'struct loadparm_context' (total    166 bytes in   5 blocks)
    /usr/local/etc/smb4.conf       contains     25 bytes in   1 blocks (ref 0) 0x800a49060
    passdb backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a74f00
    passdb backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a74020
    passbd backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a730d0
>>> a.dump_a_parameter('passdb backend')
tdbsam
>>> talloc.report_full(a)
full talloc report on 'struct loadparm_context' (total    181 bytes in   6 blocks)
    passdb backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a75440
    /usr/local/etc/smb4.conf       contains     25 bytes in   1 blocks (ref 0) 0x800a49060
    passdb backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a74f00
    passdb backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a74020
    passbd backend                 contains     15 bytes in   1 blocks (ref 0) 0x800a730d0
```
Obviously this is a minor issue because the get() method is probably more appropriate in most circumstances.

lpcfg_dump_a_parameter() calls talloc_strdup() for the parm_name passed into it so that we can check whether it's a parametric entry. Memory is allocated under the loadparm context passed into the function.

Primary consumer of this is "testparm" command and so the context is short-lived in the typical use-case, but this is also exposed via pyparam and so the loadparm context may be somewhat longer-lived depending on how it is being used.

Will attach gitlab MR for fix as comment.