tables: Remove INDEX requirement for ADDITIONAL option

[theopolis]

We do not need an explicit INDEX column for ADDITIONAL to work. If the ADDITIONAL option is set the constraint should be passed into the virtual table context.

[directionless]

Seems reasonable. Feels this is very much a choice of the underlying implementation

[theopolis]

Yeah, I’m going to take time and review the virtual table code again to make sure this does not have side effects.

[theopolis]

IIRC tables that have the ADDITIONAL option should not implement ROWID.

[directionless]

How many table implement rowid anyhow?

[theopolis]

All tables without a column marked index=True will implement rowid. Tables that do not always full-scan should not have a rowid. This protects them from unwanted optimization within SQLite.

Tables without a defined primary key, and an additional behavior, will now implicitly define a primary key as a unique row via defining a primary key equal to all columns in a row.

[directionless]

In lieu of deeper docs, from today's office hours:

The intent of #6104 is to start cleaning this up. We think:

1. The underlying table implementions will only get column constraints that have additional or index set
2. index hints to sqlite that that column is indexed, and should be taken into account during join planning
3. additional is passed to the underlying implementation, but not be taken into query planning

And for primary keys:

index columns	additional columns	resultant primary key
Yes	No	Union of index columns
Yes	Yes	Union of index and additional
No	Yes	Union of all columns
No	No	Internal sqlite rowid

A good example of how this plays out, is the routes table. It has an
additional column which changes what's generated. But, it's not
indexed. However, if we use the internal rowid calling routes with
the different additional options, they'll overwrite eachother. Thus,
using all columns.

[directionless]

Seems okay? I did not build/test though