fix: make block_number optional + allow non-interactive pull all

[greatmerlin]

Summary

Two changes, both prompted by vega pull all aborting on the newest cards.

1. fix: don't abort the whole scrape when a card has no Standard block

The newest cards on the official site (e.g. OP16-063 Kuzan) have no Standard block assigned yet, so the dd>div.backCol>div.col2>div.block element is empty. fetch_block_number treated this as fatal:

ERROR vega] failed to scrape data about card `OP16-063`: card.block_number is empty!

…which aborts the entire pull all run partway through.

This changes Card.block_number from i32 to Option<i32>, and fetch_block_number now returns Ok(None) when the block node is absent or contains no digits, instead of bail!-ing. Genuine parse errors (non-empty, non-numeric) still error.

Note: this makes block_number nullable in the serialized output — such cards now emit "block_number": null instead of crashing the run.

2. feat: non-interactive pull all via -o and --with-images

pull all was always interactive (inquire prompts for language, output dir, images), so it couldn't be scripted or run in CI. Now, when -o/--output is supplied, pull all skips the prompts and takes the language from -l/--language and the image choice from a new -a/--with-images flag (mirroring pull cards). With no -o, the interactive flow is unchanged.

# scriptable now:
vega pull -l english -o ./data all        # cards only
vega pull -l english -o ./data all -a     # cards + images

Testing

• cargo build --release is clean.
• vega pull -l english -o data all -a scrapes all 53 packs + 4571 images with no crash; OP16-063 is captured with block_number: null.

[coko7]

Hi @greatmerlin,
Thank you for your contribution.

It seems your fork is not rebased to the latest upstream commit. Part of your PR was already fixed by #10.
Please rebase first, I will gladly review your PR afterwards :)