deal with long index names and internal sqlite3 operations

The source was this issue #8264

### the problem

When creating an index the length is verified against the database limit. This allows you to create an index with a name that uses up all available characters.

We have internal operations, which rely on prefixing the index to circumvent name collisions. These internal functions will fail when dealing with long indices (`prefix + index name > database limit`).

### proposed solution

I see two possible solutions.

1. We can get rid of the internal functionality that relies on prefixing
1. We reserve a range of characters, which rails can use to perform transformations

Since I'm not sure what impact 1.) would have and if it is even possible I did a draft of 2.)

### up for discussion

There are already methods, which hold the maximum allows characters for index names, column names, table names, etc.. (`index_name_length`, `column_name_length`, `table_name_length`). I'm not sure if we should subtract the reserved character count directly from these lengths.

* + If we subtract the reserved count directly we need much fewer modifications
* - we loose the actual database limit

Currently I only applied the changes to the index names. I think table names and possible column names are affected as well.

### current solution

Some adapter (SQLite3) need to perform renaming operations to support the rails DDL. These rename prefixes operate with prefixes. When an index name already uses up the full space provieded by `index_name_length` these internal operations will fail. This patch introduces `allowed_index_name_length` which respects the amount of characters used for internal operations. It will always be <= `index_name_length` and every adapter can define how many characters need to be reserved.