egui_plot features to enable region-oriented use cases

I'm working on an application containing a musical pattern editor, which is basically a grid divided into musical notes on the Y axis (imagine a sideways piano keyboard), and a period of time, representing a single musical measure, divided into 16 or 32 sections on the X axis. Each division would have a horizontal or vertical line, forming a visible grid. Users would click the boxes in the grid to create or delete notes. This is very close to an appropriate use case for egui_plot, with at least these exceptions:

1. The grid-marker labels on the axes belong to the boxes (regions), not the lines (points). Instead of drawing a marker center-aligned with the grid lines, they'd be in between adjacent lines. I could imagine a new attribute of `Plot` that treats the spaces rather than dividers as the labeled entities.
2. The overall area of the grid has a finite bound; for example, it might be 88 notes vertically (pianos have 88 keys), and 16 notes horizontally (for a typical 4/4 time signature with each of four beats divided into 4 subdivisions). There would be no reason to allow the user to zoom wider than 88 x 16 in this example. I have experimented with `set_plot_bounds()` inside `plot.show()` to clamp it to the desired bounds, but it's super-janky. I would add a new optional `Plot` attribute that specifies a maximum area, and enforce it properly in the `egui_plot` code, rather than expecting the app to do it manually. (This might also mitigate the impact of issues like emilk/egui#3656, emilk/egui#3462, and emilk/egui#970.)

There might be more changes, but this is what my research has shown so far.

Is there interest in these enhancements? I might be able to give them a try.