Add ubuntu-family distribution support to lmdb.1.0

[jmid]

I spotted this in #28931

Linux distributions derived from Ubuntu are consider os-family="ubuntu". One such example is Mint, with

os                linux           # Inferred from system
os-distribution   linuxmint       # Inferred from system
os-family         ubuntu          # Inferred from system

According to https://github.com/ocaml/opam-repository/wiki/Depexts-os-distribution---os-family-values
this should also be the case for Ubuntu itself.

I no longer think that is the case, and that the wiki table entry for Ubuntu is wrong.
Looking at an Ubuntu CI run of #28931, e.g.,
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/8f00c13a54683097cc781d46df0c18b7f635d303/variant/distributions,ubuntu-24.04-ocaml-5.4,lmdb.1.0
I see

# system               arch=x86_64 os=linux os-distribution=ubuntu os-version=24.04

[...]

The following system packages will first need to be installed:
    liblmdb-dev pkg-config

<><> Handling external dependencies <><><><><><><><><><><><><><><><><><><><><><>

opam believes some required external dependencies are missing. opam can:
> 1. Run apt-get to install them (may need root/sudo access)
  2. Display the recommended apt-get command and wait while you run it manually (e.g. in another terminal)
  3. Continue anyway, and, upon success, permanently register that this external dependency is present, but not detectable
  4. Abort the installation

[1/2/3/4] 1

+ /usr/bin/sudo "apt-get" "install" "-qq" "-yy" "liblmdb-dev" "pkg-config"

[...]

1. annoyingly os-family isn't printed by opam config report
2. I see the liblmdb-dev depext being installed, meaning it must have matched the line ["liblmdb-dev"] {os-family = "debian"} from before this PR (no other lines name exactly that package).

In conclusion:

• this PR adds support for Ubuntu-derivatives
• our current wiki table has a wrong entry

[jmid]

After having now established in #28930 (comment) that this PR doesn't affect any distribution tested by our current CI, this should be a noop, and hence good to go.

#28931 goes further to actually address some of the observed failures.