gptel: Allow dynamically overriding preset parameters during apply

[kmontag]

If a preset's :pre callback returns a plist, use it to augment/override the preset's normal specification.

This is a proposed implementation for "functional" presets, as discussed in #905 (though it's a bit different than the solution discussed there).

I believe it's also a more generic solution to the issue that's currently being solved by the special handling of :append in presets that specify :tools. If a preset wants to specify :prompt-transform-functions, for example, this change allows appending or inserting into the current global gptel-prompt-transform-functions, rather than overwriting it.

Naturally this would somewhat change the contract of the :pre function, and if there's anyone out there who's idly returning a plist, this could introduce unexpected side effects. I don't expect that's a particularly common case. However, another option would be to use a more explicitly-named field like :override for this function, instead of :pre.

[kmontag]

By the way, I realized it's also already possible to do something like this directly in the :pre or :post function:

(gptel-make-preset
 'remove-blacklisted-tool
 ;; ...
 :pre
 (lambda ()
   (set
    'gptel-tools
    (seq-remove (lambda (tool) (equal (gptel-tool-name tool) "blacklisted_tool_name")) gptel-tools))))

However, this would assume the use of set to apply the preset settings, which isn't always the case.

[kmontag]

Update: only allow modifying keys which are already present in the spec (i.e. you can't add new ones). Otherwise, gptel--preset-syms wouldn't necessarily pick up all the symbols that are being set.