complexity of `orbits` and hence `toricBlowup` is exponential for blowing up at a point

Nobody has claimed this yet.

I noticed that `toricBlowup` for a point in `PP^n` seems to grow exponentially: ~1s, ~3s, ~10s, ~60s for n=14,15,16,17. Try this with:
```m2
n = 17; elapsedTime toricBlowup(toList(0..n-1), toricProjectiveSpace n)
```
The main bottleneck seems to be computation of the orbits.

I haven't read the implementation carefully, but even if the implemented algorithm is optimal for the general case, there are a few potential improvements here for a student or workshop:
1. Both `toricBlowup` and `orbits` could be improved using mutable lists and hash tables.
2. Blowups at points should be trivial to compute using a simpler algorithm.
3. The basis for the Picard group chosen for these special blowups could also be chosen better. In #4014 I added a WeilToClass option to specify my own degree map, but ideally this should be automatic.

cc: @ggsmith

Start by running the `toricBlowup(toList(0..n-1), toricProjectiveSpace n)` example and reading the implementations of `toricBlowup` and `orbits`, which the issue identifies as the bottleneck. Determine which improvement is in scope and compare runtime and resulting blowups for point centers before and after the change.

Written by the indexing model from the issue text.