Extend documentation for params extension

[SamWindell]

I've been working the params header recently, and while I've not had any real issues, there's been plenty of times that I've had to pause for a moment and check things, or have had things leave a niggling doubt about if I'm doing it right.

1. Firstly, functions often have an argument double *value. Given the context, I am quite confident it means that the argument is an output parameter that should be written to. I also assume that it will not be null. However, I feel like we could avoid any doubts but making this clearer with a different name and/or an extra line of documentation.

2. Secondly we have char *display and uint32_t size, which again given the context I'm pretty sure means that we have an output buffer that is of length size and should be written too including a null terminator. Again, this can be made explicit with names/comments.

3. Lastly we also have this function bool(CLAP_ABI *value_to_text)(const clap_plugin_t *plugin, clap_id param_id, double value, char *display, uint32_t size);. We are given an argument double value which I am not 100% clear about. I guess it's the value we should stringify, rather than lookup our own value using the clap_id param_id. If that's the case, it suggests that our own parameter values could be different to what the host wants to stringify?

I'm happy to make changes and a pull request if that's appropriate.

[abique]

1. likely, I'd need more context
2. certainly
3. value_to_text(): formats the given value for the given parameter. It is independent of the current parameter value. Consider an enumerated parameter, you'd use that function to pre-fetch all values name

If you want, you can make a PR to improve the doc.