cl, ro commands with less duplication

* `y2m ro` does not claim to clone from the r/w url
* both r/w and r/o cloning emit the same message
y2m: get_repos w/o grep

grep | sed is seldom useful, it wasn't here
Merge pull request #7 from roman-neuhauser/remote-url

cl, ro commands with less duplication
Merge pull request #8 from roman-neuhauser/degrep

y2m: get_repos w/o grep
redundant sed(1) gone

* don't introduce commas just to remove them
* there are no double quotes in the data
list_repos made redundant by IFS

the sed in list_repos was necessary because `echo "$foo"` preserves
newlines in $foo, and fold(1) does not join short lines.
OTOH, `echo $foo` runs Field Splitting on $foo using $IFS, which
includes LF by default.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
Merge pull request #9 from roman-neuhauser/list_repos

list_repos gone
get_repos observes 304 Not Modified

a step towards offline operation, get_repos keeps repository listings
on disk, issues http requests with If-None-Match using the ETag from
the cached data, and reuses said data when github says 304 Not Modified.

while it's not offline-capable yet it's way faster than the previous
impl which always did 5 curl requests for each of yast, libyui.
(with per_page=100, even though there's just 163 repos in yast/ and
 11 in libyui.)

it's faster because the common case is just two requests, one for each
github org, both resulting in 304 and short-circuiting the fetching
right there.

it's also not as prone to running into github's throttling of api
requests (60 per ip address per hour), which i managed to run into
at home.

BTW, i'm not sure if it's appropriate to short-circuit the fetching
on the first 304 response: does github invalidate all ETags when
a single page in the listing changes?
Merge pull request #10 from roman-neuhauser/get_repos-304

get_repos observes 304 Not Modified