Re: Allow table AMs to define their own reloptions

> That requires AMs to inherit standard option names rather than
> redefine

It looks a lot better this way, but shouldn't the documentation
mention somewhere that AMs that don't do this, like
dummy_custom_table_am can fail to restore --no-table-access-method
dumps from other AMs?

+
+/* The standard options, all of which dummy_table_am accepts */
+static const relopt_parse_elt dt_std_options[] = {
+ {"fillfactor", RELOPT_TYPE_INT,
+ offsetof(struct DummyTableOptions, std.fillfactor)},

and

+ for (int j = 0; j < lengthof(dt_std_options); j++)
+ {
+ add_reloption_to_kind(dt_std_options[j].optname, dt_relopt_kind);
+ dt_relopt_tab[i++] = dt_std_options[j];
+ }
+

Wouldn't a helper be useful for this based on / around
stdRdOptionsTab, so that it doesn't require this much fragile
copy-pasting?