Currently, using SEPARATING_LINE will produce broken HTML tables. E.g.

from tabulate import tabulate, SEPARATING_LINE

table = [["Earth",6371],
         ["Mars",3390],
         SEPARATING_LINE,
         ["Moon",1737]]
print(tabulate(table, tablefmt="html"))

produces

<table>
<tbody>
<tr><td>Earth</td><td style="text-align: right;">6371</td></tr>
<tr><td>Mars </td><td style="text-align: right;">3390</td></tr>
</tbody>
</table>
<tr><td>Moon </td><td style="text-align: right;">1737</td></tr>
</tbody>
</table>

This appears to be due to html's linebelowheader configuration to be false, so the code falls through to produce "</tbody></table>".

The merge request replaces the linebelowheader for html and unsafehtml with a function that generates a colspan'ed row with a HR tag, and ensures that the HR row isn't added below the header. So the above example results in:

<table>
<tbody>
<tr><td style="text-align: left;">Earth</td><td style="text-align: right;">6371</td></tr>
<tr><td style="text-align: left;">Mars </td><td style="text-align: right;">3390</td></tr>
<tr><td colspan="2"><hr></td></tr>
<tr><td style="text-align: left;">Moon </td><td style="text-align: right;">1737</td></tr>
</tbody>
</table>

This is valid HTML, so at least the advertised functionality for SEPARATING_LINE does not break.

Some options / considerations:

1. Another option, rather than another row, is to impose a border-top style on the row following the SEPARATING_LINE. That would be a more extensive change in the code, but would probably be prettier and would allow the table to have continuous rows or values (maybe better for cut/pasting into Excel?). On the other hand, having a specific separating row is reasonable and fits in better with the current code.
2. This PR is un-styled, which is probably more flexible / unopinionated, but the resulting HR doesn't look pretty out of the box. (In particular, it would be nice if the separating row took less vertical space.) While people can add a css rule for it (e.g. something targeting tr td hr), it might be better to add a class (e.g. tabulate-separating-row), to make it more specific to target. I think that html styling (adding classes to the tabulate-generated elements, and/or allowing users to specify local styles somehow, for jupyter or email environments) is out of scope of the PR but it would be a good discussion.
3. I think that there are other bugs for SEPARATING_LINE, e.g. SEPARATING_LINE doesn't work with tablefmt='orgtbl'. #250. The approach of this PR could be used for those other TableFormats, as needed. Alternatively, maybe there could be a more generic solution, e.g. a specific tablefmt configuration item for separating lines.