TableAM: Reloptions are bound only to relkind, they need also be included in the API.

[Eulerizeit]

Reloptions are bound only to relkind, they need also be included in table AM API.

Example:
A relkind of type sequence should never allow for the reloption fillfactor. A relkind of type relation should not always allow for the option fillfactor.

Specifically reloptions need to also be bound to the TableAM in order to ensure that the options make sense for the storage type.

Because of this we need to create multiple if/else statements, reorder code, and suffer.

Currently the only place this exists in the code without a new storage option is in the HeapOptions / ToastOptions code. We have introduced a new relkind for AO as a work around for this.

A solution will be that if we need a new storage option for one specific storage then that option should be of relkind relation.
A relkind relation should be addable without changing code over the TableAM API layer, and no other storage should accept it.

CURRENT WORK: (not far enough)
https://www.postgresql.org/message-id/flat/5578311.AeZzQnSgRP@x200m