Creating too many BIDs makes the REVEAL exceed TX policy weight

Currently, the wallet exposes one RPC call to send/create reveals, and it attempts to reveal all of your wallet's bids for a name. It's possible to have so many bids that the resulting transaction exceeds the TX policy weight, which prevents it from getting mined.

It's easier to make this happen when your coins are very fragmented, but I can consistently encounter this behavior when I call `sendreveal` on a domain with ~595 bids. Note: everything here likely also applies to redeems/etc, and also to the `create*` version of those calls.

## Solutions

I'm happy to implement the workaround for this, but there are a couple of options here and I would appreciate some help thinking through which is best:

### Option 1: Limit # reveals with a count

Accept a "count" parameter that will reveal up to `${count}` bids in the final transaction. This would require the client to repeatedly call `sendreveal` to ensure all of their bids get revealed.

This is the easiest to implement and also easiest to understand.

### Option 2: Reveal as many as possible

Always reveal the maximal number of bids. It's the responsibility of the client to call `sendreveal` again if they want to reveal the rest of their bids. This improves on the default behavior which will forever fail to generate a viable transaction.

This is harder to implement because the relationship between # bids revealed and TX size is nonlinear -- depending on the lockup amount, the number of inputs required to pay for each additional bid can vary greatly. Would need to do some weird (& potentially expensive) binary search to determine how many bids can fit in a TX.

### Option 3: Generate multiple transactions

Implement option 2, but perform that logic repeatedly until all of the bids have been revealed. This results in multiple transactions being created at the same time.

This results in the clearest behavior for the user, since they just need to worry about what they want to get done ("reveal all my bids please") and not how it will happen ("reveal these 50, then these 70, etc etc"). Shares similar shortcomings to option 2, but has a slightly stranger spec since it involves broadcasting multiple TXs.

--

I'm leaning towards option 1 since on mainnet, the reveal period is 10 days, so it's not a big deal if clients need to remember to manually submit multiple TXs during that time frame.

Other considerations: if option 2/3, then this should probably be a new RPC call (`sendlotsofreveals` etc), but if option 1, then I think it would make sense to add an additional optional parameter with a large default value to the normal `sendreveal` call.