refactor: revisit column ID assignment

[xxchan]

During work in https://github.com/risingwavelabs/risingwave/pull/17293, we can see it's a mess. It's error-prone and we cannot understand how it works precisely.

• In some places, we use ColumnId::placeholder(), and use col_id_gen to fill it at the end
• In other places, we create column id ad-hoc. AND MAY OR MAY NOT use col_id_gen again to assign the col id.

• For TableVersion we have next_column_id, but not for SourceVersion. This means DROP COLUMN for source might be problematic (although we don't support it).

  However, it's also possible that it can work. As https://github.com/risingwavelabs/risingwave/pull/17293#discussion_r1645359822, perhaps (fixed) column id for source is not relied on, but we have no clue yet.

A little more background:

• ColumnIdGenerator is introduced in https://github.com/risingwavelabs/risingwave/pull/7083
• After the refactor https://github.com/risingwavelabs/risingwave/pull/10307, we introduced ColumnId::placeholder(). This makes coding easier, but also more error-prone.

• https://github.com/risingwavelabs/risingwave/issues/9828 also mentioned:

  avoid manipulating columns manually, which bypasses ColumnIdGenerator and can be problematic if we support ALTER TABLE with connector

[xxchan]

Another factor to consider: In iceberg it's required to have a field_id, including nested types' fields (should be unique in the table schema), which will be used in schema evolution and column projection.

• https://arrow.apache.org/docs/cpp/parquet.html#parquet-field-id
• https://github.com/apache/iceberg/blob/main/format/spec.md#schemas-and-data-types