Subtile support

[tangxifan]

Is your feature request related to a problem? Please describe.

Thanks @ganeshgore to initiate the discussion and code changes, the tile annotation is one of the code changes we should expect.
Moreover, the subtile support may require changes in netlist generators, testbench generators and even bitstream generators.
A valid and specific testcase is required to ensure that the support is operating.
I consider to force pin constraints in the testcase, where we assign nets to two types of subtiles in an I/O tile at a specific location, e.g., [1][0].
Alternatively, we may create an artificial FPGA architecture, where there is only one I/O tile that consists of two types of subtiles.

A stronger testcase to have multiple (>2) types of subtiles in an I/O tile and validate the correctness of netlists.

Describe the solution you'd like

More than the example shown in #828, I believe we should support the index of subtiles, as VTR allows us to define multiple subtiles for each type.

Here is an template:

<tile_annotations>
    <global_port name="clk0" is_clock="true" default_val="0">
      <tile name="<tile_name>.<sub_tile_name>[<int>:<int>]" port="clk[0:0]" x="-1" y="-1"/>

• An illustrative example:

<tile_annotations>
    <global_port name="clk0" is_clock="true" default_val="0">
      <tile name="io.io_input[0:7]" port="clk[0:0]" x="-1" y="-1"/>

• Optionally, user can define a specific subtile with index.

<tile_annotations>
    <global_port name="clk0" is_clock="true" default_val="0">
      <tile name="io.io_input[1:1]" port="clk[0:0]" x="-1" y="-1"/>

• Optionally, user can include all the subtiles without given any index.

<tile_annotations>
    <global_port name="clk0" is_clock="true" default_val="0">
      <tile name="io.io_input" port="clk[0:0]" x="-1" y="-1"/>

where all the clock pin clk[0] of all the subtile io_input (assume we may have N subtiles in this type). We do not need users to write io_input[0:N-1] explicitly.

[ganeshgore]

@tangxifan Thank you for evaluating the PR;

The variations you proposed look good and make sense to me.

While we are at it, we should also consider the pin_mapping functionality.
If this feature is also functional, we can have better naming for tile pins containing subtitles.

It seems that it should work by default after the above changes. But for the tile_annotation section, we will have to specify what to refer pb_type pins or tile pins