feat: regex and dynamic-metadata rewrite

[henryiii]

Based on scikit-build/dynamic-metadata#1 (with some updates). Fixes #435.

This doesn't start using tool.dynamic-metadata yet, to give us room to change that. Plus we have to back-compat support tool.scikit-build.metadata, so might as well keep that as the only way to set this for now.

[henryiii]

A few thoughts: (A) Should we have a write_to / template pair of options for the regex plugin? (B) Or should we put metadata file writing into scikit-build-core generally? (C) Or should we build in something to dynamic-metadata to handle this generally? One benefit of the last one is that you could probably keep from writing the file out into the source tree - except probably with editable installs.

I think I'm pretty strongly in favor of B, maybe along with a mention in dynamic-metadata of how backends could do this.

Actually, we can control the location of the output (wheel, build dir, or source dir), so I'm very strongly in favor of B.

[henryiii]

@bennyrowland - I'm making this small change to the interface for plugins following scikit-build/dynamic-metadata#1. Let me know if there are any issues. I've been moving ahead with option B above, so will likely merge this soon and then open a PR for option B. (edit: I actually don't think they conflict too much, might open it now).

[bennyrowland]

@henryiii, sorry for the slow response, sadly my time allocation for responding to OSS issues doesn't align well with your extremely rapid development cycle. But rest assured that I am continuing to follow along with developments as much as I can. This is the change so that each plugin gets called per field, rather than allowing one plugin to provide multiple field values in a single call? I can understand that this makes the API rather simpler/cleaner and in practice it is unlikely to be much of an issue (I guess that in extremis a plugin could cache the results of its expensive run and regurgitate those values in subsequent calls).

I also wanted to say that I really like the new "write metadata to file" implementation, it is very elegant. The only thing I wanted to query was about whether you had any thoughts about alternative templating options (like Jinja or Mako) which could then have more general purpose Python code embedded in them. That would make the generate settings into a more versatile file generation option which could also be used for generating things like build logs with timestamps or the values of environment variables, and probably a whole bunch of other use cases. I don't have a particular need for this kind of thing, but it just occurred to me looking at the changes and wondered what your perspective was.