allow dashes (and possibly other valid path symbols) in the site names

Desired Behavior

The following shall be accepted:

(install
  (files stdio.lisp)
  (package bap-primus-lisp)
  (section (site (bap site-lisp))))

Instead, it fails with

File "plugins/primus_lisp/site-lisp/dune", line 4, characters 22-31:
4 |   (section (site (bap site-lisp))))
                          ^^^^^^^^^
Error: "site-lisp" is an invalid site name.
Module names must be non-empty and composed only of the following characters:
'A'..'Z', 'a'..'z', '_', ''' or '0'..'9'.
Hint: site_lisp would be a correct site name

The justification is that dashes are commonly used as word separators in UNIX paths and allowing dashes (and other symbols) will make it easier (and possible) to integrate with the existing packages.

I understand that the site name will be used as an OCalm identifier, but paths could be normalized, e.g., dashes could be translated to underscores, e.g., val Sites.site_lisp : string = ".../share/bap/site-lisp.

Alternatively, the syntax of the site specification could be extended to accept a path string, e.g.,

(package
  (name bap)
  (sites (lib plugins)
         (share lisp)
         (share (site_lisp as "site-lisp")) ;; like this
         (share semantics)))

Though a quick glance to the implementation suggests that it will be a much more invasive change. It also opens a pandora's box of path canonicalization and security issues, e.g., (site_lisp as "/etc/passwd").

Also, if you have any immediate workarounds for installing files at other packages locations that are not constrained with the site module, I will be happy to hear about them.

Start with plugins/primus_lisp/site-lisp/dune and the failing site-name validation shown in the report. Trace how the site name becomes Sites.site_lisp, then determine whether the supported change is allowing dashes with normalization or adding the proposed path-string syntax. Done means the reported site declaration is accepted without compromising path safety.