Fix updatepreferred to handle JLC API changes

[z2amiller]

It appears that at some point, JLC has changed the way it reports the page numbering when
iterating the preferred components. I noticed this while I was investigating another issue, that
there were exactly 1000 preferred components, that seemed suspiciously like a hardcoded limit.

It looks like the API response from JLC has changed, and it reports 'hasNextPage: false' even when
there are remaining pages. It looks like the API now reports the number of pages and the current
page, so I've changed the updatepreferred command to use this instead.

(body->data->componentPageInfo):

endRow: 0
hasNextPage:  false
hasPreviousPage: false
isFirstPage:  false
isLastPage: false
list:  (1000) [{…},  …]
navigateFirstPage: 0
navigateLastPage: 0
navigatePages: 0
navigatepageNums: null
nextPage: 0
pageNum: 1
pageSize: 1000
pages: 2
prePage: 0
size: 0
startRow: 0
total: 1234

With and without the change:

andrewmiller@Mac db_working % cp cache.sqlite3 /tmp/.
andrewmiller@Mac db_working % sqlite3 /tmp/cache.sqlite3 'select sum(basic > 0) as basic_parts, sum(preferred > 0) as preferred_parts, sum(basic = 0 AND preferred = 0) as extended_parts from components'
351|1000|7034887
andrewmiller@Mac jlcparts % jlcparts updatepreferred /tmp/cache.sqlite3
Fetched page 1/2 with 1000 components
Fetched page 2/2 with 234 components
andrewmiller@Mac db_working % sqlite3 /tmp/cache.sqlite3 'select sum(basic > 0) as basic_parts, sum(preferred > 0) as preferred_parts, sum(basic = 0 AND preferred = 0) as extended_parts from components'
351|1232|7034655

(I assume that 1234 != 1232 due to some parsing/etc issue somewhere but it's small enough that I didn't look into it further)